Authentification

L’onglet Auth indique comment une requête prouve son identité. Choisissez un Type, remplissez ses champs, et Echolot ajoute les identifiants à chaque envoi de la requête. Définissez l’authentification une fois sur un dossier ou sur l’espace de travail, et toutes les requêtes qu’il contient peuvent l’utiliser.

Garder les identifiants hors des fichiersCopy Anchor Link

Chaque champ accepte des {{variables}}. Mettez les mots de passe, jetons et clés dans des variables secrètes, qui vivent dans le trousseau, et écrivez {{password}} dans le champ. Ainsi, le fichier de la requête ne contient aucun secret et vous pouvez le commiter.

Quand vous saisissez une valeur en clair dans un champ d’identifiant, un avertissement apparaît dessous : Enregistré en clair dans le fichier de l’espace de travail. Cliquez sur Placer dans le trousseau et Echolot stocke la valeur comme variable secrète de l’espace de travail et écrit {{name}} à sa place.

Les identifiants qu’Echolot ajoute sont masqués là où la page de requête les affiche : dans les en-têtes AUTOMATIQUES et dans l’aperçu de l’URL sous la barre d’URL.

Hériter des dossiers et de l’espace de travailCopy Anchor Link

Hériter est le choix par défaut. Une requête qui hérite utilise l’authentification du dossier le plus proche au-dessus d’elle qui en définit une, puis celle de l’espace de travail. Sous Utilise, l’onglet indique laquelle s’applique, comme Folder “Orders”: Bearer Token, avec un bouton qui l’ouvre : Modifier l’authentification du dossier… ou Modifier l’authentification de l’espace de travail…. Quand rien au-dessus ne définit d’authentification, la requête n’en envoie aucune.

Une requête qui a sa propre authentification la garde, et son onglet Auth affiche aussi une ligne Authentification de l’espace de travail avec l’authentification de l’espace de travail et un bouton pour l’ouvrir : Authentification de l’espace de travail…, ou Configurer l’authentification de l’espace de travail… quand l’espace de travail n’en a pas encore. Authentification de l’espace de travail… se trouve aussi dans la palette de commandes (⌘K).

Pour définir l’authentification de nombreuses requêtes à la fois :

1. Dans la barre latérale, faites un clic droit sur un dossier et choisissez Réglages du dossier…. Pour l’espace de travail, utilisez Authentification de l’espace de travail… depuis l’onglet Auth d’une requête ou la palette de commandes, ou cliquez sur le sélecteur d’espace de travail en bas de la barre latérale et choisissez Réglages de l’espace de travail….
2. Ouvrez l’onglet Auth et choisissez un type. Un dossier peut aussi hériter ; l’espace de travail ne le peut pas. Sous les réglages, l’onglet indique combien de requêtes réglées sur Hériter utilisent cette authentification.
3. Pour OAuth 2.0, connectez-vous directement ici : la barre du jeton en bas fonctionne comme dans une requête (voir OAuth 2.0), et toutes les requêtes qui héritent de l’authentification utilisent ce jeton. Obtenir le jeton enregistre d’abord l’authentification. La barre n’affiche le jeton propre au dossier ou à l’espace de travail qu’une fois son authentification enregistrée : elle n’affiche donc jamais, et n’oublie jamais, un jeton qui appartient à l’authentification au-dessus.
4. Cliquez sur Terminé.

Dans l’exemple Alpenglow, le dossier Orders définit Jeton Bearer avec {{token}}, et toutes les requêtes de commande en héritent. Auth › Sign in remplit {{token}} à partir de sa réponse avec une capture.

Choisir un typeCopy Anchor Link

Un en-tête Authorization que vous ajoutez vous-même dans l’onglet En-têtes est envoyé à la place de celui que l’onglet Auth ajouterait.

BasicCopy Anchor Link

Remplissez Nom d’utilisateur et Mot de passe. Echolot les envoie encodés en Base64 dans l’en-tête Authorization. Essayez avec Echo › Basic auth dans Alpenglow.

DigestCopy Anchor Link

Remplissez Nom d’utilisateur et Mot de passe. Le premier envoi part sans identifiants ; quand le serveur répond 401 avec un défi Digest, Echolot y répond une fois avec une seconde requête. Les deux apparaissent dans l’échange comme des étapes.

Jeton BearerCopy Anchor Link

Remplissez Jeton, généralement {{token}}. Préfixe vaut Bearer par défaut ; changez-le pour un serveur qui veut un autre mot, ou effacez-le pour envoyer le jeton seul.

Clé d’APICopy Anchor Link

Remplissez Clé (le nom de l’en-tête ou du paramètre, X-API-Key par défaut) et Valeur, puis choisissez où elle va sous Ajouter dans : En-tête ou Paramètre de requête.

OAuth 2.0Copy Anchor Link

Echolot obtient le jeton d’accès pour vous et l’ajoute sous la forme Authorization: Bearer <token>.

En bas de l’onglet, la barre du jeton indique s’il y a un jeton. Cliquez sur Obtenir le jeton :

• Code d’autorisation ouvre votre navigateur sur l’URL d’autorisation. Connectez-vous-y ; Echolot intercepte la redirection et affiche Terminez la connexion dans votre navigateur… jusqu’à ce que vous l’ayez fait.
• Code d’appareil affiche Se connecter sur un autre appareil avec un code. Cliquez sur Ouvrir (avec le nom d’hôte de la page), saisissez-y le code et approuvez ; Echolot attend avec En attente d’approbation….
• Identifiants client interroge directement l’URL du jeton. Vous n’avez pas besoin de cliquer sur Obtenir le jeton pour cet octroi : le premier envoi obtient un jeton tout seul.
• Mot de passe (ancien) envoie le nom d’utilisateur et le mot de passe à l’URL du jeton, et ne demande pas non plus de clic : le premier envoi obtient un jeton. Utilisez-le uniquement pour d’anciennes API qui l’exigent. Cet octroi est obsolète parce que le mot de passe lui-même quitte votre Mac : préférez Code d’autorisation quand le serveur le propose.

Echolot ne propose pas l’octroi implicite, lui aussi obsolète. La plupart des serveurs qui l’offrent encore offrent aussi Code d’autorisation, ce en quoi un octroi implicite importé est converti ; vérifiez que le serveur l’accepte.

Dès qu’il y a un jeton, la barre indique Jeton d’accès dans le trousseau, avec son type, sa date d’expiration, s’il se renouvelle automatiquement et sa portée. Obtenir un nouveau jeton le remplace ; Oublier le supprime.

Comment les jetons sont conservés et utilisés :

• Les jetons sont stockés dans le trousseau, jamais dans les fichiers de l’espace de travail.
• Un jeton appartient à la requête, au dossier ou à l’espace de travail qui définit l’authentification, et à l’environnement et aux réglages pour lesquels il a été émis : changer d’environnement, ou modifier l’URL du jeton, l’ID client, la portée ou un autre réglage qui détermine à qui le jeton est destiné, utilise ou obtient un jeton à part et n’envoie jamais un jeton émis pour autre chose. Les requêtes qui héritent d’OAuth d’un dossier partagent ses jetons. Oublier supprime les jetons de tous les environnements.
• Quand un jeton a expiré, l’envoi suivant le renouvelle avec son jeton de renouvellement. Un jeton Identifiants client ou Mot de passe est obtenu de nouveau. Sinon, l’envoi s’arrête avec Cette requête a besoin d’un jeton OAuth : obtenez-en un dans l’onglet Auth d’abord. ou Le jeton OAuth a expiré et n’a pas pu être renouvelé : obtenez-en un nouveau dans l’onglet Auth.

Pour essayer, envoyez Auth › Orders with OAuth 2 dans Alpenglow : elle utilise Identifiants client contre l’API de démo.

AvancéCopy Anchor Link

La plupart des serveurs n’en ont pas besoin ; c’est donc replié sous Avancé. La section s’ouvre d’elle-même quand quelque chose y est défini.

• Renouveler automatiquement est activé par défaut. Désactivez-le pour envoyer un jeton expiré tel quel et voir comment l’API y répond. Un premier jeton est quand même obtenu pour Identifiants client et Mot de passe.
• URL de renouvellement sert aux serveurs dont le endpoint de renouvellement n’est pas l’URL du jeton. Vide, c’est l’URL du jeton.
• Demande d’autorisation, Demande de jeton et Demande de renouvellement ajoutent des paramètres pour les serveurs qui veulent plus que les champs standard : access_type = offline chez Google (pour qu’il fournisse un jeton de renouvellement), resource pour Azure AD, un tenant ou une version d’API. Chaque ligne a une clé, une valeur (les variables fonctionnent, les secrets peuvent donc rester dans le trousseau) et, pour les demandes de jeton et de renouvellement, l’endroit où elle va : Corps, En-tête ou URL. Un paramètre du même nom qu’un paramètre standard le remplace. Les paramètres de la demande d’autorisation vont dans l’adresse de connexion, ou dans la demande d’autorisation d’appareil pour Code d’appareil. Ils ne remplacent jamais le state ni le défi PKCE.

OAuth 1.0Copy Anchor Link

Pour les API qui utilisent encore OAuth 1.0 : NetSuite, Magento et Adobe Commerce, les endpoints v1.1 de X, ou les liens d’application de Jira ou Confluence Server, entre autres. Echolot signe chaque requête avec un jeton que vous avez déjà. Il n’exécute pas le flux à trois branches qui permet d’en obtenir un, et Postman non plus.

1. Choisissez la Méthode de signature : HMAC-SHA1 (la plus courante), HMAC-SHA256, HMAC-SHA512, RSA-SHA1, RSA-SHA256, RSA-SHA512 ou PLAINTEXT.
2. Remplissez Clé consommateur, puis Secret consommateur, ou pour RSA une Clé privée (collez-la, ou cliquez sur Choisir un fichier PEM… pour la placer directement dans le trousseau).
3. Remplissez Jeton d’accès et, sauf pour RSA, Secret du jeton. Laissez-les vides pour une requête faite avant qu’il y ait un jeton.
4. Sous Ajouter dans, choisissez En-tête (Authorization: OAuth …, par défaut), URL ou Corps. Corps signe dans un corps de formulaire, ou dans l’adresse pour une requête qui n’en a pas.
5. Avancé contient Realm, URL de rappel et Vérificateur (pour les étapes du flux à trois branches que vous faites à la main), Ajouter oauth_version="1.0" (activé par défaut) et Inclure le hachage du corps dans la signature (oauth_body_hash, pour les corps qui ne sont pas des formulaires).

Chaque requête est signée à l’envoi, avec un nouvel horodatage et un nouveau nonce, sur la méthode, l’adresse, sa query string et les champs d’un corps de formulaire.

Signature AWSCopy Anchor Link

Remplissez ID de clé d’accès, Clé d’accès secrète, Région (us-east-1 par défaut) et Service (execute-api par défaut ; s3, lambda, es, etc.). Jeton de session ne sert que pour les identifiants temporaires. Chaque requête est signée à l’envoi, avec l’heure, l’hôte et le corps avec lesquels elle part.

JWT BearerCopy Anchor Link

Echolot signe un nouveau jeton à chaque envoi.

1. Choisissez l’Algorithme : HS256, HS384 ou HS512 (HMAC avec un secret), RS256, RS384, RS512, PS256, PS384 ou PS512 (clé privée RSA), ou ES256 ou ES384 (clé privée à courbe elliptique).
2. Pour HMAC, remplissez Secret ; cochez Secret en Base64 quand le fournisseur vous l’a donné ainsi. Pour une clé privée, collez-la dans Clé privée, ou cliquez sur Choisir un fichier PEM… : la clé va directement dans le trousseau et le champ y fait référence par son nom. Les clés peuvent être au format PEM PKCS #8, PKCS #1 ou SEC 1.
3. Écrivez les Claims en JSON. Ils peuvent contenir des variables : {"sub": "{{userID}}"}.
4. Ajoutez des Champs d’en-tête comme kid si le serveur en a besoin. alg et typ sont définis pour vous.
5. Ajouter « iat » (émis le) est activé par défaut. Expire après ajoute exp à ce nombre de secondes dans le futur (300 par défaut) ; 0 n’en ajoute aucun. Les claims que vous définissez vous-même dans le JSON sont conservés tels qu’écrits.
6. Sous Ajouter dans, choisissez En-tête (avec un Préfixe, Bearer par défaut) ou Paramètre de requête (avec un nom de Paramètre, token par défaut).

HawkCopy Anchor Link

Remplissez ID et Clé, choisissez l’Algorithme (SHA-256 ou SHA-1), et ajoutez Données d’app (ext) si le serveur le veut. Cochez Inclure le hachage du corps dans la signature pour inclure le hachage de la charge. Chaque requête est signée avec l’heure, un nonce, la méthode, le chemin, l’hôte et le port.

Akamai EdgeGridCopy Anchor Link

Remplissez Jeton client, Secret client et Jeton d’accès. En-têtes à signer est une liste séparée par des virgules, généralement vide. Octets du corps signés limite la quantité du corps d’un POST qui est hachée (131072 par défaut).

NTLMCopy Anchor Link

Remplissez Nom d’utilisateur et Mot de passe, ainsi que Domaine et Poste de travail si votre serveur en a besoin. Echolot parle NTLMv2 : il répond au défi du serveur sur la même connexion, et les 401 restent dans l’échange comme des étapes.

NTLM authentifie une connexion, pas une requête : il nécessite donc HTTP/1.1. Avec la version HTTP sur Automatique, Echolot utilise HTTP/1.1 pour les requêtes NTLM ; avec HTTP/2 ou HTTP/3 choisi, l’envoi est refusé. Voir Réglages de la requête.

Les identifiants restent avec leur origineCopy Anchor Link

Quand une redirection mène à une autre origine (un autre schéma, hôte ou port), Echolot n’y emporte pas vos identifiants. Il abandonne :

• les en-têtes Authorization, Proxy-Authorization et Cookie,
• les en-têtes de clé d’API courants (X-API-Key, Api-Key, Apikey, X-Auth-Token, X-Access-Token, Private-Token, X-Functions-Key), l’en-tête qu’utilise votre authentification Clé d’API, et tout en-tête dont la valeur contient une variable secrète,
• les signatures Digest, AWS Signature, OAuth 1.0, Hawk, EdgeGrid et NTLM, ainsi que le certificat client choisi pour le premier hôte.

Les certificats et le proxy du nouvel hôte s’appliquent à l’étape qui y mène. Voir Réglages de la requête.

Environnements protégésCopy Anchor Link

Obtenir le jeton envoie aussi une requête. Quand l’environnement de la fenêtre est protégé, il demande d’abord confirmation, comme Envoyer. Voir Environnements protégés.