Authentification
Restorm n’a pas de menu déroulant « type d’authentification ». Il a quelque chose de plus général : la requête d’authentification, une requête à part entière dont le rôle est de produire des en-têtes pour les autres.
L’avantage : n’importe quel schéma se modélise, y compris ceux qu’aucune liste déroulante ne prévoit — un échange en deux temps, un jeton signé, une API maison. L’inconvénient : il faut l’écrire une fois.
Créer une route d’authentification
Section titled “Créer une route d’authentification”Clic droit sur un dossier de variables ▸ Ajouter ▸ Requête d’authentification.
Configurez d’abord l’appel comme n’importe quelle requête HTTP : méthode, URL, en-têtes, corps. Puis ouvrez son onglet Configuration, qui porte les trois réglages propres à l’authentification.
En-têtes produits
Section titled “En-têtes produits”La liste des en-têtes que cette route injectera dans toute requête qui la référence. Chaque valeur est une expression évaluée sur le corps de la réponse de la requête d’authentification.
| En-tête | Valeur |
|---|---|
Authorization | {{token_type}} {{access_token}} |
Expiration (secondes)
Section titled “Expiration (secondes)”Une expression, également évaluée sur le corps de la réponse, qui donne la
durée de validité en secondes — typiquement {{expires_in}}. Laissée vide,
le jeton n’expire jamais tout seul.
Codes d’erreur d’authentification
Section titled “Codes d’erreur d’authentification”Les statuts HTTP qui, reçus par une requête utilisant cette route, déclenchent
un renouvellement du jeton puis un réessai automatique. Par défaut :
401 et 403.
Deux termes, une seule chose
Section titled “Deux termes, une seule chose”Une requête d’authentification est l’élément que vous créez dans l’arbre. Une route d’authentification est ce même élément vu depuis une autre requête, dans le sélecteur qui l’attache. Les deux termes désignent la même entité, à deux endroits de l’interface.
Attacher une route à une requête
Section titled “Attacher une route à une requête”Sur l’onglet de la requête, dans la smartbar, un sélecteur Route d’authentification liste les routes du dossier de variables. Le libellé par défaut est Aucune authentification.
Une fois attachée, les en-têtes produits sont injectés à chaque envoi, le jeton
est mis en cache jusqu’à son expiration, et un 401 provoque un renouvellement
transparent.
Recettes courantes
Section titled “Recettes courantes”Bearer / OAuth 2 client credentials
Section titled “Bearer / OAuth 2 client credentials”Requête : POST https://auth.exemple.test/oauth/token, corps
x-www-form-urlencoded avec grant_type=client_credentials,
client_id={{clientId}}, client_secret={{clientSecret}}
(le secret étant une valeur de type Secret).
En-tête produit : Authorization = {{token_type}} {{access_token}}.
Expiration : {{expires_in}}.
Aucune requête n’est nécessaire si vous avez déjà les identifiants : posez simplement l’en-tête sur la requête (ou sur le dossier) :
Authorization = Basic {{base64Encode (append (append user ":") password)}}
Clé d’API
Section titled “Clé d’API”Un en-tête ou un paramètre de requête suffit :
X-API-Key = {{apiKey}}, la clé étant une variable de type Secret.
Jeton obtenu en deux appels
Section titled “Jeton obtenu en deux appels”Créez un scénario : premier appel, extraction
du code intermédiaire, second appel, puis Définir variable pour poser le
jeton dans les variables de run. Les requêtes suivantes du scénario le lisent
avec {{jeton}}.
Ce que fait l’import
Section titled “Ce que fait l’import”À l’import d’une spécification, les schémas de sécurité déclarés sont traduits en en-têtes ou paramètres pré-câblés, avec une variable d’environnement créée pour vous :
| Schéma dans la spécification | Ce que Restorm pose |
|---|---|
apiKey (en-tête ou requête) | Un couple nommé d’après le schéma, valeur {{<schema>}} |
http / basic | Authorization: Basic {{<schema>_credentials}} |
http / bearer, oauth2, openIdConnect | Authorization: Bearer {{<schema>_token}} |
Il ne vous reste qu’à renseigner la variable, ou à la remplacer par une route d’authentification si vous voulez le renouvellement automatique.
Identifiants natifs par protocole
Section titled “Identifiants natifs par protocole”Certains protocoles ne passent pas par des en-têtes HTTP. Leurs identifiants sont des champs de la requête elle-même :
| Protocole | Champs |
|---|---|
| MQTT | username, password, identifiant client |
| AMQP | username, password, vhost |
| Redis | password |
| Kafka | Mécanisme SASL (plain, scram-sha-256, scram-sha-512), identifiant, mot de passe, TLS |
| STOMP | En-têtes login et passcode du CONNECT |
| gRPC | Métadonnées de l’appel |
Chacun de ces mots de passe accepte une valeur de type Secret.