quijano.com.es

En-tête dautorisation oauth2

Dans ce blog, vous découvrirez ce qui suit :

  • En-tête
  • d’autorisation Comment utiliser l’en-tête d’autorisation

Prenons une brève idée des en-têtes de demande d’autorisation.

Qu’est-ce qu’un en-tête de demande d’autorisation ?

L’en-tête de demande d’autorisation HTTP contient les informations d’identification pour authentifier un agent utilisateur auprès d’un serveur.

Les API utilisent l’autorisation pour s’assurer que les demandes du client accèdent aux données en toute sécurité. Il peut s’agir d’authentifier l’expéditeur d’une demande et de vérifier qu’il est autorisé à accéder aux données concernées ou à les manipuler. Si vous créez une API, vous pouvez choisir parmi différents modèles d’authentification. Si vous intégrez une API tierce, le fournisseur d’API spécifiera l’autorisation requise.

Liste des en-têtes de demande d’autorisation

Il existe de nombreux types de demande d’autorisation En-têtes. Certains d’entre eux sont mentionnés ci-dessous.

  • Authentification de base
  • Jeton du porteur
    • API
  • Résumé
    • de
  • la clé
  • Authentification OAuth 2.0
  • Hawk Signature
  • AWS

1. Il

s’agit d’un schéma d’authentification simple intégré au protocole HTTP. Le client envoie des requêtes HTTP avec l’en-tête Authorization qui contient le mot , suivi d’un espace et d’une chaîne de caractères codée en base64 (non chiffrée) nom d’utilisateur : password. Par exemple, pour autoriser en tant que nom d’utilisateur / Pa$$w 0rd, le client enverrait ce qui suit :

Remarque : L’encodage Base64 ne signifie pas le cryptage ou le hachage ! Par conséquent, cette méthode équivaut à envoyer les informations d’identification en texte clair comme ABCXYZ (base64 est un encodage réversible). Préférez utiliser HTTPS en conjonction avec l’authentification de base.

deux. Jeton du porteur

Communément appelé authentification par jeton, il s’agit d’un schéma d’authentification HTTP qui implique des jetons de sécurité appelés jetons de porteur. Comme son nom l’indique, « Bearer Authentication » donne accès au porteur de ce jeton.

Le jeton du porteur est une chaîne cryptique, généralement générée par le serveur en réponse à une demande de connexion. Le client doit envoyer ce jeton dans l’en-tête Authorization lors de la demande de ressources protégées :

À l’instar de l’authentification de base, l’authentification du porteur ne doit être utilisée que via HTTPS (SSL). Pour l’authentification JWT, l’authentification du porteur est recommandée

3. Clé API

Une clé API est un jeton qu’un client fournit lors d’appels API. Avec l’authentification par clé API, vous envoyez une paire clé-valeur à l’API dans les en-têtes de requête ou les paramètres de requête. Certaines API utilisent des clés API pour l’autorisation.

La clé dans la chaîne de requête :

Ou en tant que requête En-tête :

4. L’authentification Digest

communique les informations d’identification sous une forme chiffrée en appliquant un algorithme de hachage au nom d’utilisateur et au mot de passe. Le mot de passe est converti en réponse, puis il est envoyé au serveur. Après cela, le serveur fournit la valeur nonce, la méthode HTTP et l’URI demandé.

L’authentification d’accès HTTP Digest est une forme d’authentification plus complexe qui fonctionne comme suit :

  1. Le client envoie une requête au serveur.

  2. Le serveur répond avec un code spécial (appelé nonce, c’est-à-dire un numéro utilisé une seule fois) et une autre chaîne représentant le domaine (un hachage) pour l’authentification du client.

  3. Le client répond avec ce nonce et une version chiffrée du nom d’utilisateur, du mot de passe et du domaine (un hachage).

  4. Si le hachage du client correspond au serveur hachage, le serveur répondra avec les informations demandées. Sinon, il passera un message d’erreur.

5. Planche à billets OAuth2.0

OAuth 1.0 permet aux applications clientes d’accéder aux données fournies par une API tierce. Par exemple, en tant qu’utilisateur d’un service, vous pouvez accorder à une autre application l’accès à vos données avec ce service sans exposer vos informations de connexion.

Avec OAuth 2.0, vous récupérez d’abord un jeton d’accès pour l’API, puis vous utilisez ce jeton pour authentifier les demandes futures. L’accès aux informations via le flux OAuth 2.0 varie considérablement d’un fournisseur de services d’API à l’autre, mais implique généralement quelques requêtes en amont et en aval entre une application cliente, un utilisateur et une API.

Un flux OAuth 2.0 fonctionne comme suit :

  1. une application cliente demande à l’utilisateur d’autoriser l’accès à ses données.

  2. Si l’utilisateur accorde l’accès, le L’application demande un jeton d’accès au fournisseur de services, en transmettant l’octroi d’accès de l’utilisateur et les détails d’authentification pour identifier le client.

  3. Le fournisseur de services valide ces détails et renvoie un jeton d’accès.

  4. Le client utilise le jeton d’accès pour demander les données de l’utilisateur via le prestataire de services.

6. Planche à voile L’authentification Hawk

vous permet d’autoriser les demandes à l’aide d’une vérification cryptographique partielle.

Les paramètres d’authentification Hawk sont les suivants :

  • ID d’authentification Hawk : Votre valeur d’ID d’authentification API.
  • Hawk Auth Key : La valeur de votre clé d’authentification API.
  • Algorithme : L’algorithme de hachage (sha266, sha1) utilisé pour créer le code d’authentification des messages (MAC).

Dans l’en-tête de la demande, il se présente comme suit :

7. AWS Signature

AWS Signature est le flux d’autorisation pour les demandes Amazon Web Services. AWS utilise un schéma HTTP personnalisé basé sur un HMAC (Hash Message Authentication Code) à clé pour l’authentification.

Les paramètres d’authentification AWS sont les suivants :

  • Clé d’accès : Valeur de la clé d’accès API
  • Clé secrète : Valeur de la clé secrète de l’API

Lorsque vous vous inscrivez, un ID de clé d’accès AWS et une clé d’accès secrète vous sont attribués. Pour l’authentification de la demande, l’élément identifie l’ID de la clé d’accès utilisée pour calculer la signature et, indirectement, le développeur qui effectue la demande.

Dans l’en-tête de la requête, cela se présente comme suit :

Conclusion

Vous avez appris à utiliser différents en-têtes de demande d’autorisation sur l’API Appels.

Écrit par Ankit Singh

C’est un développeur curieux qui aime réfléchir profondément au monde qui l’entoure. Il adore bloguer sur ce qu’il apprend et explore de temps en temps de nouvelles technologies.