ZW3B :-: API Client * Contents * Docs by LAB3W.ORJ

NdM : 2021/09/09 - Cette page est en cours de complément rédactionnel..

OAuth : Protocole d'Autorisation

OAuth est un standard ouvert pour l'accès délégation, communément utilisé comme un moyen pour les utilisateurs d'Internet d'accorder l'accès aux sites Web ou à des applications, à leurs informations sur d'autres sites Web, mais sans leur donner les mots de passe.

Introduction

En règle générale, OAuth fournit aux clients un "accès délégué sécurisé" aux ressources du serveur au nom d'un propriétaire de ressource. Il spécifie un processus permettant aux propriétaires de ressources d'autoriser l'accès aux ressources de leur serveur à des tiers sans fournir d'informations d'identification.

Conçu spécifiquement pour fonctionner avec Hypertext Transfer Protocol (HTTP), OAuth permet essentiellement d'émettre des jetons d'accès à des clients tiers par un serveur d'autorisation, avec l'approbation du propriétaire de la ressource. Le tiers utilise alors le jeton d'accès pour accéder aux ressources protégées hébergées par le serveur de ressources.

En particulier, OAuth 2.0 fournit des flux d'autorisation spécifiques pour les applications Web, les applications de bureau, les téléphones mobiles et les appareils intelligents.

RFC 6749 - 1.1. Rôles :

OAuth définit quatre rôles :

• Propriétaire de la ressource (resource owner) :
  Entité capable d'accorder l'accès à une ressource protégée.
  Lorsque le propriétaire de la ressource est une personne, on parle de utilisateur final.
• Serveur de ressources (resource server) :
  Le serveur hébergeant les ressources protégées, capable d'accepter et répondre aux demandes de ressources protégées à l'aide de jetons d'accès.
• Client (client) :
  Une application effectuant des demandes de ressources protégées au nom du propriétaire de la ressource et avec son autorisation. Le terme "client" ne n'implique aucune caractéristique de mise en œuvre particulière (par exemple, si l'application s'exécute sur un serveur, un bureau ou autre dispositifs).
• Serveur d'autorisation (authorization server) :
  Le serveur émettant des jetons d'accès au client après avoir réussi authentifier le propriétaire de la ressource et obtenir l'autorisation.

L'interaction entre le serveur d'autorisation et le serveur de ressources dépasse le cadre de cette spécification. Le serveur d'autorisation peut être le même serveur que le serveur de ressources ou une entité distincte. Un seul serveur d'autorisation peut émettre des jetons d'accès acceptés par plusieurs serveurs de ressources.

RFC 6749 - 1.2. Flux de protocole :

Script avec 19 lignes

001Figure 1 : Flux de protocole abstrait (Abstract Protocol Flow)
002          
003+--------+                               +---------------+
004|        |--(A)- Authorization Request ->|   Resource    |
005|        |                               |     Owner     |
006|        |<-(B)-- Authorization Grant ---|               |
007|        |                               +---------------+
008|        |
009|        |                               +---------------+
010|        |--(C)-- Authorization Grant -->| Authorization |
011| Client |                               |     Server    |
012|        |<-(D)----- Access Token -------|               |
013|        |                               +---------------+
014|        |
015|        |                               +---------------+
016|        |--(E)----- Access Token ------>|    Resource   |
017|        |                               |     Server    |
018|        |<-(F)--- Protected Resource ---|               |
019+--------+                               +---------------+

Le flux OAuth 2.0 abstrait décrit l'interaction entre les quatre rôles et comprend les étapes suivantes :

• (A) Le client demande l'autorisation du propriétaire de la ressource. Les la demande d'autorisation peut être faite directement au propriétaire de la ressource (comme indiqué), ou de préférence indirectement via l'autorisation serveur en tant qu'intermédiaire.
• (B) Le client reçoit un octroi (accord) d'autorisation (authorization grant), qui est un identifiant représentant l'autorisation du propriétaire de la ressource, exprimé à l'aide de l'un des quatre types de subventions définis dans la présente spécification ou en utilisant un type d'octroi d'extension. Les type d'octroi (d'attribution) de l'autorisation dépend de la méthode utilisée par le client pour demander l'autorisation et les types pris en charge par le serveur d'autorisation.
• (C) Le client demande un jeton d'accès en s'authentifiant auprès du serveur d'autorisation et présentant l'octroi d'autorisation.
• (D) Le serveur d'autorisation authentifie le client et valide l'octroi de l'autorisation et, s'il est valide, émet un jeton d'accès token).
• (E) Le client demande la ressource protégée à la ressource serveur et s'authentifie en présentant le jeton d'accès (token).
• (F) Le serveur de ressources valide le jeton d'accès et, s'il est valide, sert la demande.

La méthode privilégiée par le client pour obtenir un octroi d'autorisation du propriétaire de la ressource (représenté dans les étapes (A) et (B)) est d'utiliser le serveur d'autorisation en tant qu'intermédiaire, ce qui est illustré dans Figure 3 dans la section 4.1.

RFC 6749 - 1.3. Octroi (Attribution) d'autorisation (Authorization Grant)

Un octroi (une attribution) d'autorisation est un justificatif représentant l'autorisation du propriétaire de la ressource (pour accéder à ses ressources protégées) utilisée par le client pour obtenir un jeton d'accès (token).
Cette spécification définit quatre types d'octroi (accord) :

1. code d'autorisation (authorization code),
2. implicite (implicit),
3. Paire identifiant / mot de passemot de passe du propriétaire de la ressource - ses informations d'identification (resource owner password credentials)
4. et les informations d'identification du client (client credentials) ainsi qu'un mécanisme d'extensibilité pour définir des types supplémentaires.

RFC 6749 - 1.3.1. Code d'autorisation (Authorization Code)

Le code d'autorisation est obtenu en utilisant un serveur d'autorisation en tant qu'intermédiaire entre le client et le propriétaire de la ressource. A la place de demander l'autorisation directement au propriétaire de la ressource, le client dirige le propriétaire de la ressource vers un serveur d'autorisation (via son user-agent tel que défini dans [ RFC2616 ]), qui à son tour dirige le propriétaire de la ressource au client avec le code d'autorisation.

Avant de rediriger le propriétaire de la ressource vers le client avec le code d'autorisation, le serveur d'autorisation authentifie le propriétaire de la ressource et obtient l'autorisation. Parce que le propriétaire de la ressource s'authentifie uniquement auprès du serveur d'autorisation, la ressource les informations d'identification du propriétaire ne sont jamais partagées avec le client.

Le code d'autorisation offre quelques avantages de sécurité importants, telles que la capacité d'authentifier le client, ainsi que la transmission du jeton d'accès directement au client sans le faire passer par l'agent utilisateur du propriétaire de la ressource et potentiellement l'exposer à d'autres, y compris le propriétaire de la ressource.

RFC 6749 - 1.3.2. Implicite (Implicit)

L'octroi (l'attribution) implicite (Implicit grants) est un flux de code d'autorisation simplifié optimisé pour les clients implémentés dans un navigateur utilisant un langage de script tel comme JavaScript. Dans le flux implicite, au lieu d'émettre au client un code d'autorisation, le client reçoit directement un jeton d'accès (à la suite de l'autorisation du propriétaire de la ressource). Le type de subvention est implicite, car aucune information d'identification intermédiaire (telle qu'une autorisation code) sont émis (et utilisés plus tard pour obtenir un jeton d'accès).

Lors de l'émission d'un jeton d'accès (access token) pendant le flux d'octroi implicite (implicit grant flow), le serveur d'autorisation (authorization server) n'authentifie pas le client. Dans certaines cas, l'identité du client peut être vérifiée via l'URI de redirection utilisé pour fournir le jeton d'accès (access token) au client. Le jeton d'accès peut être exposé au propriétaire de la ressource ou à d'autres applications ayant accès à l'agent utilisateur du propriétaire de la ressource.

Les octrois (les attributions) implicites (Implicit grants) améliorent la réactivité et l'efficacité de certains clients (comme un client implémenté en tant qu'application dans le navigateur), puisqu'il réduit le nombre d'allers-retours nécessaires pour obtenir un jeton d'accès (access token). Cependant, cette commodité doit être mise en balance des implications de sécurité de l'utilisation d'attributions (d'octrois) implicites (implicit grants), telles que celles décrites aux sections 10.3 et 10.16 , en particulier lorsque le le type d'octroi de code d'autorisation est disponible.

RFC 6749 - 1.3.3. Paire identifiant / mot de passe du propriétaire de la ressource - ses informations d'identification (Resource Owner Password Credentials)

Les informations d'identification du propriétaire de la ressource (c'est-à-dire le nom d'utilisateur et le mot de passe) peut être utilisé directement comme une autorisation pour obtenir un accès jeton (access token). Les informations d'identification ne doivent être utilisées que lorsqu'il y a un degré de confiance entre le propriétaire de la ressource et le client (p. le client fait partie du système d'exploitation de l'appareil ou d'un demande) et lorsque d'autres types d'octroi d'autorisation ne sont pas disponible (comme un code d'autorisation).

Même si ce type de subvention nécessite un accès client direct au informations d'identification du propriétaire de la ressource, les informations d'identification du propriétaire de la ressource sont utilisées pour une seule demande et sont échangés contre un jeton d'accès. Cette type de subvention peut éliminer le besoin pour le client de stocker le les informations d'identification du propriétaire de la ressource pour une utilisation future, en échangeant les informations d'identification avec un jeton d'accès de longue durée ou un jeton d'actualisation.

RFC 6749 - 1.3.4. Identifiants du client (Client Credentials)

Les informations d'identification du client (ou d'autres formes d'authentification client) peuvent être utilisé comme un octroi (une attribution) d'autorisation lorsque la portée de l'autorisation est limité aux ressources protégées sous le contrôle du client, ou à des ressources protégées préalablement aménagées avec l'autorisation serveur. Les informations d'identification du client sont utilisées comme octroi (attribution) d'autorisation généralement lorsque le client agit pour son propre compte (le client est également le propriétaire de la ressource) ou demande l'accès à des ressources sur la base d'une autorisation préalablement convenue avec le serveur d'autorisation.

RFC 6749 - 1.4. Jeton d'accès (Access Token)

Les jetons d'accès sont des informations d'identification utilisées pour accéder aux ressources protégées. Un le jeton d'accès est une chaîne représentant une autorisation délivrée au client. La chaîne est généralement opaque pour le client. Jetons représentent des étendues et des durées d'accès spécifiques, accordées par le propriétaire de la ressource, et appliqué par le serveur de ressources et l'autorisation serveur.

Le jeton peut désigner un identifiant utilisé pour récupérer l'autorisation informations ou peut contenir les informations d'autorisation dans un manière vérifiable (c'est-à-dire une chaîne de jeton composée de certaines données et d'un Signature). Informations d'authentification supplémentaires, qui vont au-delà la portée de cette spécification, peut être nécessaire pour client d'utiliser un jeton.

Le jeton d'accès fournit une couche d'abstraction, remplaçant différentsconstructions d'autorisation (par exemple, nom d'utilisateur et mot de passe) avec un seul jeton compris par le serveur de ressources. Cette abstraction permet émission de jetons d'accès plus restrictifs que l'octroi d'autorisation utilisé pour les obtenir, ainsi que la suppression du besoin du serveur de ressources pour comprendre un large éventail de méthodes d'authentification.

Les jetons d'accès peuvent avoir différents formats, structures et méthodes de utilisation (par exemple, propriétés cryptographiques) en fonction de la ressource exigences de sécurité du serveur. Attributs de jeton d'accès et les méthodes utilisées pour accéder aux ressources protégées dépassent le cadre de cette spécification et sont définis par des spécifications d'accompagnement telles comme [ RFC6750 ].

RFC 6749 - 1.5. Jeton d'actualisation (Refresh Token)

Les jetons d'actualisation (refresh token) sont des informations d'identification utilisées pour obtenir des jetons d'accès (access token). Rafraîchir les jetons (token) sont émis au client par le serveur d'autorisation et sont utilisés pour obtenir un nouveau jeton d'accès (access token) lorsque le jeton d'accès actuel (access token) devient invalide ou expire, ou pour obtenir des jetons d'accès (access token) supplémentaires avec une portée identique ou plus étroite (les jetons d'accès (access token) peuvent avoir une durée de vie et moins d'autorisations que celles autorisées par la ressource propriétaire). L'émission d'un jeton d'actualisation (resfresh token) est facultative à la discrétion du serveur d'autorisation (authorization server). Si le serveur d'autorisation (authorization server) émet une actualisation jeton (refresh token), il est inclus lors de l'émission d'un jeton d'accès (c'est-à-dire, l'étape (D) dans Figure 1).

Un jeton d'actualisation (refresh token) est une chaîne représentant l'autorisation accordée à le client par le propriétaire de la ressource. La chaîne est généralement opaque pour le client. Le jeton (token) désigne un identifiant utilisé pour récupérer le informations d'autorisation. Contrairement aux jetons d'accès (access token), les jetons d'actualisation (refresh token) sont destinés à être utilisés uniquement avec des serveurs d'autorisation et ne sont jamais envoyés aux serveurs de ressources.

Script avec 22 lignes

001Figure 2: Actualisation d'un jeton d'accès expiré (Refreshing an Expired Access Token)
002          
003+--------+                                           +---------------+
004|        |--(A)------- Authorization Grant --------->|               |
005|        |                                           |               |
006|        |<-(B)----------- Access Token -------------|               |
007|        |               & Refresh Token             |               |
008|        |                                           |               |
009|        |                            +----------+   |               |
010|        |--(C)---- Access Token ---->|          |   |               |
011|        |                            |          |   |               |
012|        |<-(D)- Protected Resource --| Resource |   | Authorization |
013| Client |                            |  Server  |   |     Server    |
014|        |--(E)---- Access Token ---->|          |   |               |
015|        |                            |          |   |               |
016|        |<-(F)- Invalid Token Error -|          |   |               |
017|        |                            +----------+   |               |
018|        |                                           |               |
019|        |--(G)----------- Refresh Token ----------->|               |
020|        |                                           |               |
021|        |<-(H)----------- Access Token -------------|               |
022+--------+           & Optional Refresh Token        +---------------+

• (A) Le client demande un jeton d'accès en s'authentifiant auprès du serveur d'autorisation et présentant une autorisation d'octroi.
• (B) Le serveur d'autorisation authentifie le client et valide l'octroi de l'autorisation, et s'il est valide, émet un jeton d'accès et un jeton d'actualisation.
• (C) Le client fait une demande de ressource protégée à la ressource serveur en présentant le jeton d'accès.
• (D) Le serveur de ressources valide le jeton d'accès et, s'il est valide, sert la demande.
• (E) Les étapes (C) et (D) se répètent jusqu'à l'expiration du jeton d'accès. Si la le client sait que le jeton d'accès a expiré, il passe à l'étape (G) ; sinon, il fait une autre demande de ressource protégée.
• (F) Puisque le jeton d'accès n'est pas valide, le serveur de ressources renvoie une erreur de jeton invalide.
• (G) Le client demande un nouveau jeton d'accès en s'authentifiant avec le serveur d'autorisation et présentant le jeton de rafraîchissement. Les les exigences d'authentification du client sont basées sur le type de client et sur les politiques du serveur d'autorisation.
• (H) Le serveur d'autorisation authentifie le client et valide le jeton d'actualisation et, s'il est valide, émet un nouveau jeton d'accès (et, éventuellement, un nouveau jeton d'actualisation).

Les étapes (C), (D), (E) et (F) sortent du cadre de ce spécification, comme décrit dans la section 7 .

RFC 6749 - 1.6. Version TLS

Chaque fois que Transport Layer Security (TLS) est utilisé par ce spécification, la version (ou les versions) appropriée de TLS variera au fil du temps, sur la base du déploiement généralisé et de la sécurité connue vulnérabilités. Au moment d'écrire ces lignes, TLS version 1.2 [ RFC5246 ] est la version la plus récente, mais a une portée très limitée base de déploiement et pourrait ne pas être facilement disponible pour la mise en oeuvre. TLS version 1.0 [ RFC2246 ] est le plus largement version déployée et fournira l'interopérabilité la plus large.

Les implémentations PEUVENT également prendre en charge une sécurité supplémentaire de la couche de transport mécanismes qui répondent à leurs exigences de sécurité.

RFC 6749 - 1.7. Redirections HTTP

Cette spécification fait un usage intensif des redirections HTTP, dans lesquelles le client ou le serveur d'autorisation dirige le propriétaire de la ressource user-agent vers une autre destination. Alors que les exemples de ce spécification montrent l'utilisation du code d'état HTTP 302, tout autre méthode disponible via l'agent utilisateur pour accomplir cette redirection est autorisé et est considéré comme un détail de mise en œuvre.

RFC 6749 - 1.8. Interopérabilité (Interoperability)

OAuth 2.0 fournit un cadre d'autorisation riche avec des propriétés de sécurité. Cependant, en tant que riche et hautement extensible framework avec de nombreux composants facultatifs, à lui seul, ce spécification est susceptible de produire un large éventail de implémentations.

De plus, cette spécification laisse quelques composants requis partiellement ou totalement indéfini (par exemple, l'enregistrement du client, capacités du serveur d'autorisation, découverte des points de terminaison). Sans ces composants, les clients doivent être manuellement et spécifiquement configuré par rapport à un serveur d'autorisation et une ressource spécifiques serveur afin d'interopérer. Ce cadre a été conçu avec l'espoir clair que l'avenir les travaux définiront les profils prescriptifs et les extensions nécessaires pour obtenir une interopérabilité complète à l'échelle du Web.

RFC 6749 - 1.9. Conventions de notation (Notational Conventions)

Les mots clés The key words "MUST (DOIT)", "MUST NOT (NE DOIT PAS)", "REQUIRED (OBLIGATOIRE)", "SHALL (DEVRA)", "SHALL NOT (NE DEVRA PAS)", "SHOULD (DEVRAIT)", "SHOULD NOT (NE DEVRAIT PAS)", "RECOMMENDED (CONSEILL1Eacute;)", "MAY (PEUT)", and "OPTIONAL (OPTIONNEL)" dans cette spécification doivent être interprétés comme décrit dans [ RFC2119 ].

Cette spécification utilise la forme Augmented Backus-Naur Form Backus-Naur augmentée (ABNF) notation de [ RFC5234 ]. De plus, la règle URI-reference est inclus dans "Uniform Resource Identifier (URI): Generic Syntax" [ RFC3986 ].

Certains termes liés à la sécurité doivent être compris dans le sens défini dans la [ RFC4949 ]. Ces termes incluent, sans s'y limiter, "attack (attaque)", "authentication (authentification)", "authorization (autorisation)", "certificate (certificat)", "confidentiality (confidentialité)", "credential (identifiant)", "encryption (chiffrement)", "identity (identité)", "sign (signe)", "signature (signature)", "trust (confiance)", "validate (valider)" et "verify (vérifier)".

Sauf indication contraire, tous les noms et valeurs des paramètres de protocole sont sensibles à la case.

RFC 6749 - 2. Inscription des clients (Client Registration)

Avant d'initier le protocole, le client s'enregistre auprès du serveur d'autorisation. Les moyens par lesquels le client s'inscrit avec le serveur d'autorisation dépassent le cadre de ce spécification mais impliquent généralement une interaction de l'utilisateur final avec un code HTML formulaire d'inscription.

L'enregistrement du client ne nécessite pas d'interaction directe entre le client et le serveur d'autorisation. Lorsqu'il est soutenu par le serveur d'autorisation, l'enregistrement peut s'appuyer sur d'autres moyens pour établir la confiance et obtenir les propriétés requises du client (par exemple, URI de redirection, type de client). Par exemple, l'enregistrement peut être accomplie à l'aide d'une assertion auto-émise ou émise par un tiers, ou par le serveur d'autorisation effectuant la découverte du client à l'aide d'un canal de confiance.

Lors de l'enregistrement d'un client, le développeur client DOIT :

• spécifier le type de client comme décrit dans la section 2.1,
• fournir ses URI de redirection client comme décrit dans la section 3.1.2, et,
• inclure toute autre information requise par le serveur d'autorisation (par exemple, le nom de l'application, le site Web, la description, l'image du logo, l'acceptation des mentions légales).

RFC 6749 - 2.1. Types de clients (Client Types)

OAuth définit deux types de clients, en fonction de leur capacité à s'authentifier en toute sécurité auprès du serveur d'autorisation (c'est-à-dire la capacité de préserver la confidentialité de leurs identifiants clients) :

• confidential (confidentiel)
  Les clients capables de préserver la confidentialité de leurs informations d'identification (par exemple, client implémenté sur un serveur sécurisé avec accès restreint aux informations d'identification du client), ou capable de sécuriser authentification du client par d'autres moyens.
• public (publique)
  Les clients incapables de maintenir la confidentialité de leurs informations d'identification (par exemple, les clients s'exécutant sur le périphérique utilisé par le propriétaire de la ressource, telle qu'une application native installée ou un site Web application basée sur un navigateur) et incapable de sécuriser le client authentification par tout autre moyen.

La désignation du type de client est basée sur le serveur d'autorisation définition de l'authentification sécurisée et de son exposition acceptable niveaux d'informations d'identification des clients. Le serveur d'autorisation NE DEVRAIT PAS faire des hypothèses sur le type de client.

Un client peut être implémenté sous la forme d'un ensemble distribué de composants, chacun avec un type de client et un contexte de sécurité différents (par exemple, un client distribué avec à la fois un composant confidentiel basé sur un serveur et un composant public basé sur un navigateur). Si le serveur d'autorisation ne fournit pas de soutien à ces clients ou ne fournit pas conseils concernant leur inscription, le client DEVRAIT enregistrer chaque composant en tant que client distinct.

Cette spécification a été conçue autour du client suivant profils :

• web application (application Web)
  Une application Web est un client confidentiel s'exécutant sur un site Web serveur. Les propriétaires de ressources accèdent au client via un utilisateur HTML interface rendue dans un user-agent sur l'appareil utilisé par le propriétaire de la ressource. Les identifiants du client ainsi que tout accès token émis au client sont stockés sur le serveur Web et sont non exposé ou accessible par le propriétaire de la ressource.
• user-agent-based application (application basée sur l'agent utilisateur)
  Une application basée sur un agent utilisateur est un client public dans lequel le le code client est téléchargé à partir d'un serveur Web et s'exécute dans un user-agent (par exemple, un navigateur Web) sur l'appareil utilisé par la ressource propriétaire. Les données de protocole et les informations d'identification sont facilement accessibles (et souvent visible) au propriétaire de la ressource. Étant donné que de telles applications résident dans l'agent utilisateur, ils peuvent utiliser de manière transparente le capacités d'agent utilisateur lors de la demande d'autorisation.
• native application (application native)
  Une application native est un client public installé et exécuté surle périphérique utilisé par le propriétaire de la ressource. Données de protocole et les informations d'identification sont accessibles au propriétaire de la ressource. Il est supposé que toutes les informations d'authentification client incluses dans le l'application peut être extraite. D'autre part, dynamiquement les informations d'identification émises telles que les jetons d'accès ou les jetons d'actualisation peuven bénéficier d'un niveau de protection acceptable. Au minimum, ces les identifiants sont protégés des serveurs hostiles avec lesquels le l'application peut interagir. Sur certaines plateformes, ces identifiants peut être protégé contre d'autres applications résidant sur le même dispositif.

RFC 6749 - 2.2. Identifiant client (Client Identifier)

Le serveur d'autorisation délivre au client enregistré un client identifiant -- une chaîne unique représentant l'enregistrement informations fournies par le client. L'identifiant client n'est pas un secret; il est exposé au propriétaire de la ressource et NE DOIT PAS être utilisé seul pour l'authentification du client. L'identifiant client est unique à le serveur d'autorisation.

La taille de la chaîne d'identifiant client n'est pas définie par ce spécification. Le client doit éviter de faire des suppositions sur le taille de l'identifiant. Le serveur d'autorisation DEVRAIT documenter la taille de tout identifiant qu'il délivre.

RFC 6749 - 2.3. Authentification des clients (Client Authentication)

Si le type de client est confidentiel, le client et l'autorisation serveur établir une méthode d'authentification client adaptée au exigences de sécurité du serveur d'autorisation. L'autorisation le serveur PEUT accepter toute forme d'authentification client répondant à ses exigences de sécurité.

Les clients confidentiels reçoivent généralement (ou établissent) un ensemble de informations d'identification client utilisées pour l'authentification avec l'autorisation serveur (par exemple, mot de passe, paire de clés publique/privée).

Le serveur d'autorisation PEUT établir une méthode d'authentification client avec les clients publics. Cependant, le serveur d'autorisation NE DOIT PAS se fier sur l'authentification du client public dans le but d'identifier le client.

Le client NE DOIT PAS utiliser plus d'une méthode d'authentification dans chaque demande (request).

RFC 6749 - 2.3.1. Mot de passe client (Client Password)

Les clients en possession d'un mot de passe client PEUVENT utiliser le HTTP Basic schéma d'authentification tel que défini dans [ RFC2617 ] pour s'authentifier avec le serveur d'autorisation. L'identifiant client est encodé à l'aide du Algorithme de codage "application/x-www-form-urlencoded" par Annexe B , et la valeur encodée est utilisée comme nom d'utilisateur ; le client le mot de passe est codé à l'aide du même algorithme et utilisé comme le mot de passe. Le serveur d'autorisation DOIT prendre en charge le HTTP Basic schéma d'authentification pour authentifier les clients qui ont reçu un mot de passe client.

Par exemple (avec des sauts de ligne supplémentaires à des fins d'affichage uniquement) :

Script avec 1 ligne

001Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

Alternativement, le serveur d'autorisation PEUT prendre en charge l'inclusion des informations d'identification du client dans le corps de la requête en utilisant les paramètres suivants :

• client_id
  OBLIGATOIRE. L'identifiant client délivré au client lors du processus d'enregistrement décrit à la section 2.2
• client_secret
  OBLIGATOIRE. Le secret client. Le client PEUT omettre le paramètre si le secret client est une chaîne vide.

Inclure les informations d'identification du client dans le corps de la requête à l'aide des deux paramètres n'est PAS RECOMMANDÉ et DEVRAIT être limité aux clients incapables d'utiliser directement le schéma d'authentification HTTP Basic (ou autre schémas d'authentification HTTP basés sur un mot de passe). Les paramètres ne peuvent être transmis dans le corps de la demande et NE DOIT PAS être inclus dans le demander l'URI.

Par exemple, une demande d'actualisation d'un jeton d'accès ( Section 6 ) en utilisantles paramètres du corps (avec des sauts de ligne supplémentaires à des fins d'affichage seul) :

Script avec 6 lignes

001POST /token HTTP/1.1
002Host: server.example.com
003Content-Type: application/x-www-form-urlencoded
004
005grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
006&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

Le serveur d'autorisation DOIT exiger l'utilisation de TLS comme décrit dans Section 1.6 lors de l'envoi de demandes à l'aide d'une authentification par mot de passe.

Étant donné que cette méthode d'authentification client implique un mot de passe, lele serveur d'autorisation DOIT protéger tout point de terminaison l'utilisant contre attaques par force brute.

RFC 6749 - 2.3.2. Autres méthodes d'authentification (Other Authentication Methods)

Le serveur d'autorisation PEUT prendre en charge toute authentification HTTP appropriée système correspondant à ses exigences de sécurité. Lors de l'utilisation d'autres méthodes d'authentification, le serveur d'autorisation DOIT définir un correspondance entre l'identifiant du client (fiche d'enregistrement) et schéma d'authentification.

RFC 6749 - 2.3.3. Clients non enregistrés (Unregistered Clients)

Cette spécification n'exclut pas l'utilisation de clients non enregistrés. Cependant, l'utilisation de tels clients dépasse le cadre de cette spécification et nécessite une analyse de sécurité supplémentaire et un examen des son impact sur l'interopérabilité.

RFC 6749 - 3. Points de terminaison de protocole (Protocol Endpoints)

RFC 6749 - 3.1. Point de terminaison d'autorisation (Authorization Endpoint)

RFC 6749 - 3.1.1. Type de réponse (Response Type)

RFC 6749 - 3.1.2. Point de terminaison de redirection (Redirection Endpoint)

RFC 6749 - 3.1.2.1. Confidentialité de la demande de point de terminaison (Endpoint Request Confidentiality)

RFC 6749 - 3.1.2.2. Conditions d'inscription (Registration Requirements)

RFC 6749 - 3.1.2.3. Configuration dynamique (Dynamic Configuration)

RFC 6749 - 3.1.2.4. Point de terminaison non valide (Invalid Endpoint)

RFC 6749 - 3.1.2.5. Contenu du point de terminaison (Endpoint Content)

RFC 6749 - 3.2. Point de terminaison du jeton (Token Endpoint)

RFC 6749 - 3.2.1. Authentification des clients (Client Authentication)

RFC 6749 - 3.3. Portée du jeton d'accès (Access Token Scope)

RFC 6749 - 4. Obtention de l'autorisation (Obtaining Authorization)

Pour demander un jeton d'accès (access token), le client obtient l'autorisation du propriétaire de la ressource. L'autorisation est exprimée sous la forme d'un octroi (attribution) d'autorisation, que le client utilise pour demander l'accès jeton (access token). OAuth définit quatre types d'attribution : code d'autorisation, implicite, les informations d'identification mot de passe du propriétaire de la ressource et les informations d'identification du client. Ça fournit un mécanisme d'extension pour définir des types d'octrois (d'attributions) supplémentaires.

RFC 6749 - 4.1 Octroi (attribution) de code d'autorisation (Authorization Code Grant)

Le type d'octroi (d'attribution) de code d'autorisation est utilisé pour obtenir à la fois l'accès jetons (token access) et jetons d'actualisation (token refresh) et est optimisé pour les clients confidentiels. Puisqu'il s'agit d'un flux basé sur la redirection, le client doit être capable d'interagir avec l'agent utilisateur du propriétaire de la ressource (généralement un navigateur) et capable de recevoir des requêtes entrantes (via redirection) du serveur d'autorisation.

Script avec 29 lignes

001Figure 3: Flux de code d'autorisation (Authorization Code Flow)
002
003+----------+
004| Resource |
005|   Owner  |
006|          |
007+----------+
008     ^
009     |
010    (B)
011+----|-----+          Client Identifier      +---------------+
012|         -+----(A)-- & Redirection URI ---->|               |
013|  User-   |                                 | Authorization |
014|  Agent  -+----(B)-- User authenticates --->|     Server    |
015|          |                                 |               |
016|         -+----(C)-- Authorization Code ---<|               |
017+-|----|---+                                 +---------------+
018  |    |                                         ^      v
019 (A)  (C)                                        |      |
020  |    |                                         |      |
021  ^    v                                         |      |
022+---------+                                      |      |
023|         |>---(D)-- Authorization Code ---------'      |
024|  Client |          & Redirection URI                  |
025|         |                                             |
026|         |<---(E)----- Access Token -------------------'
027+---------+       (w/ Optional Refresh Token)
028
029Note: Les lignes illustrant les étapes (A), (B) et (C) sont divisées en deux parties lorsqu'elles traversent l'agent utilisateur. 

Le flux illustré à la figure 3 comprend les étapes suivantes :

• (A) Le client initie le flux en dirigeant le propriétaire de la ressource user-agent au point de terminaison d'autorisation. Le client comprend son identifiant client, la portée demandée, l'état local et un URI de redirection auquel le serveur d'autorisation enverra le user-agent une fois l'accès accordé (ou refusé).
• (B) Le serveur d'autorisation authentifie le propriétaire de la ressource (via l'agent utilisateur) et établit si le propriétaire de la ressource accorde ou refuse la demande d'accès du client.
• (C) En supposant que le propriétaire de la ressource accorde l'accès, le serveur d'autorisation redirige l'agent utilisateur vers le client à l'aide de l'URI de redirection fourni précédemment (dans la demande ou lors de l'enregistrement du client). L'URI de redirection comprend un code d'autorisation et tout état local fourni par le client précédemment.
• (D) Le client demande un jeton d'accès au point de terminaison du jeton du serveur d'autorisation en incluant le code d'autorisation reçu à l'étape précédente. Lors de la demande, le client s'authentifie auprès du serveur d'autorisation. Le client inclut l'URI de redirection utilisé pour obtenir le code d'autorisation pour vérification.
• (E) Le serveur d'autorisation authentifie le client, valide le code d'autorisation et s'assure que l'URI de redirection reçu correspond à l'URI utilisé pour rediriger le client à l'étape (C). S'il est valide, le serveur d'autorisation répond avec un jeton d'accès et, éventuellement, un jeton d'actualisation.

RFC 6749 - 4.1.1. Demande d'autorisation (Authorization Request)

Le client construit l'URI de la demande en ajoutant ce qui suit paramètres au composant de requête de l'URI du point de terminaison d'autorisation en utilisant le format "application/x-www-form-urlencoded", selon l' annexe B :

• response_type
  OBLIGATOIRE. La valeur DOIT être définie sur "code".
• client_id
  OBLIGATOIRE. L'identifiant client tel que décrit à la section 2.2 .
• redirect_uri
  OPTIONNEL. Comme décrit dans la section 3.1.2 .
• scope (portée)
  OPTIONNEL. La portée de la demande d'accès telle que décrite par section 3.3 .
• state (état)
  CONSEILLÉ. Une valeur opaque utilisée par le client pour maintenir état entre la demande et le rappel. L'autorisation le serveur inclut cette valeur lors de la redirection de l'agent utilisateur au client. Le paramètre DEVRAIT être utilisé pour empêcher falsification de requêtes intersites tel que décrit à la section 10.12 .

Le client dirige le propriétaire de la ressource vers l'URI construit à l'aide d'un réponse de redirection HTTP, ou par d'autres moyens à sa disposition via l'agent utilisateur.

Par exemple, le client demande à l'agent utilisateur d'effectuer la requête HTTP suivante à l'aide de TLS (avec des sauts de ligne supplémentaires à des fins d'affichage uniquement) :

Script avec 2 lignes

001GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
002Host: server.example.com

Retirer les numéros de lignes

RFC 6749 - 4.1.2. Réponse d'autorisation (Authorization Response)

Si le propriétaire de la ressource accorde la demande d'accès, le serveur d'autorisation émet un code d'autorisation et le délivre au client en ajoutant les paramètres suivants au composant de requête de l'URI de redirection au format "application/x-www-form-urlencoded", selon l'annexe B :

• code
  OBLIGATOIRE. Le code d'autorisation généré par le serveur d'autorisation. Le code d'autorisation DOIT expirer peu de temps après sa délivrance afin d'atténuer les risques de fuites. UNE durée de vie maximale du code d'autorisation de 10 minutes est CONSEILLÉ. Le client NE DOIT PAS utiliser le code d'autorisation plus d'une fois. Si un code d'autorisation est utilisé plus d'une fois, le serveur d'autorisation DOIT refuser la demande et DEVRAIT révoquer (si possible) tous les tokens précédemment émis sur la base de ce code d'autorisation. Le code d'autorisation est lié à l'identifiant client et l'URI de redirection.
• state (état)
  OBLIGATOIRE si le paramètre "state" était présent dans le client demande d'autorisation. La valeur exacte reçue du client.

Par exemple, le serveur d'autorisation redirige l'agent utilisateur en envoyant la réponse HTTP suivante :

Script avec 2 lignes

001HTTP/1.1 302 Found
002Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

Retirer les numéros de lignes

Le client DOIT ignorer les paramètres de réponse non reconnus. Les la taille de la chaîne du code d'autorisation n'est pas définie par ce spécification. Le client doit éviter de faire des hypothèses sur le code tailles de valeur. Le serveur d'autorisation DEVRAIT documenter la taille de toute valeur qu'il émet.

RFC 6749 - 4.1.2.1. Réponse d'erreur (Error Response)

RFC 6749 - 4.1.3. Demande de jeton d'accès (Access Token Request)

Le client fait une demande au point de terminaison du jeton en envoyant le paramètres suivants en utilisant le "application/x-www-form-urlencoded" format selon l' annexe B avec un codage de caractères UTF-8 dans le protocole HTTP request entity-body :

• grant_type
  OBLIGATOIRE. La valeur DOIT être définie sur "authorization_code".
• code
  OBLIGATOIRE. Le code d'autorisation reçu du serveur d'autorisation.
• redirect_uri
  OBLIGATOIRE, si le paramètre "redirect_uri" a été inclus dans la demande d'autorisation telle que décrite à la section 4.1.1 , leur valeurs DOIVENT être identiques.
• client_id
  OBLIGATOIRE, si le client ne s'authentifie pas avec le serveur d'autorisation comme décrit dans la section 3.2.1 .

Si le type de client est confidentiel ou si le client a été émis client informations d'identification (ou d'autres exigences d'authentification assignées), le le client DOIT s'authentifier auprès du serveur d'autorisation comme décrit dans la section 3.2.1 .

Par exemple, le client effectue la requête HTTP suivante à l'aide de TLS (avec des sauts de ligne supplémentaires à des fins d'affichage uniquement) :

Script avec 7 lignes

001POST /token HTTP/1.1
002Host: server.example.com
003Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
004Content-Type: application/x-www-form-urlencoded
005
006grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
007&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Retirer les numéros de lignes

Le serveur d'autorisation DOIT :

• exiger l'authentification du client pour les clients confidentiels ou pour tout client qui a reçu des informations d'identification client (ou avec d'autres exigences d'authentification),
• authentifier le client si l'authentification client est incluse,
• s'assurer que le code d'autorisation a été délivré à la personne authentifiée client confidentiel, ou si le client est public, s'assurer que le code a été envoyé à "client_id" dans la requête,
• vérifier que le code d'autorisation est valide, et
• s'assurer que le paramètre "redirect_uri" est présent si le paramètre "redirect_uri" a été inclus dans l'autorisation initiale demande tel que décrit à la section 4.1.1 , et s'il est inclus, assurez-vous que leurs valeurs sont identiques.

RFC 6749 - 4.1.4. Réponse du jeton d'accès (Access Token Response)

Si la demande de jeton d'accès est valide et autorisée, le serveur d'autorisation émet un jeton d'accès et une actualisation facultative jeton comme décrit dans la section 5.1 . Si le client de la demande l'authentification a échoué ou n'est pas valide, le serveur d'autorisation renvoie une réponse d'erreur comme décrit dans la section 5.2 .

Exemple de réponse réussie :

Script avec 12 lignes

001HTTP/1.1 200 OK
002Content-Type: application/json;charset=UTF-8
003Cache-Control: no-store
004Pragma: no-cache
005
006{
007  "access_token":"2YotnFZFEjr1zCsicMWpAA",
008  "token_type":"example",
009  "expires_in":3600,
010  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
011  "example_parameter":"example_value"
012}

Retirer les numéros de lignes

RFC 6749 - 4.2. Octroi (attribution) implicite (Implicit Grant)

RFC 6749 - 4.2.1. Demande d'autorisation (Authorization Request)

RFC 6749 - 4.2.2. Réponse du jeton d'accès (Access Token Response)

RFC 6749 - 4.2.2.1. Réponse d'erreur (Error Response)

RFC 6749 - 4.3. Octroi des identifiants de mot de passe du propriétaire de la ressource (Resource Owner Password Credentials Grant)

Le type d'octroi (attribution) des identifiants de mot de passe du propriétaire de la ressource convient dans cas où le propriétaire de la ressource a une relation de confiance avec le client, tel que le système d'exploitation de l'appareil ou une application. Le serveur d'autorisation doit faire particulièrement attention lorsqu'il active ce type de octroi (attribution) et ne l'autoriser que lorsque les autres flux ne sont pas viable.

Ce type d'octroi (attribution) convient aux clients capables d'obtenir les informations d'identification du propriétaire de la ressource (nom d'utilisateur et mot de passe, généralement en utilisant un formulaire interactif). Il est également utilisé pour migrer les clients existants en utilisant des schémas d'authentification directe tels que HTTP Basic ou Digest, l'authentification à OAuth en convertissant les informations d'identification stockées en un jeton d'accès (access token).

Script avec 19 lignes

001Figure 5: Flux d'informations d'identification de mot de passe du propriétaire de la ressource (Resource Owner Password Credentials Flow)
002
003+----------+
004| Resource |
005|  Owner   |
006|          |
007+----------+
008     v
009     |    Resource Owner
010    (A) Password Credentials
011     |
012     v
013+---------+                                  +---------------+
014|         |>--(B)---- Resource Owner ------->|               |
015|         |         Password Credentials     | Authorization |
016| Client  |                                  |     Server    |
017|         |<--(C)---- Access Token ---------<|               |
018|         |    (w/ Optional Refresh Token)   |               |
019+---------+                                  +---------------+

Retirer les numéros de lignes

Le flux illustré à la figure 5 comprend les étapes suivantes :

• (A) Le propriétaire de la ressource fournit au client son nom d'utilisateur et le mot de passe.
• (B) Le client demande un jeton d'accès à l'autorisation point de terminaison du jeton du serveur en incluant les informations d'identification reçues du propriétaire de la ressource. Lors de la demande, le client s'authentifie auprès du serveur d'autorisation.
• (C) Le serveur d'autorisation authentifie le client et valide les informations d'identification du propriétaire de la ressource, et si elles sont valides, émet un accès jeton.

RFC 6749 - 4.3.1. Demande d'autorisation et réponse (Authorization Request and Response)

La méthode par laquelle le client obtient le propriétaire de la ressource informations d'identification est au-delà de la portée de cette spécification. Le client DOIT éliminer les informations d'identification une fois qu'un jeton d'accès a été obtenu.

RFC 6749 - 4.3.2. Demande de jeton d'accès (Access Token Request)

Le client fait une demande au point de terminaison du jeton en ajoutant le paramètres suivants en utilisant le "application/x-www-form-urlencoded" format selon l' annexe B avec un codage de caractères UTF-8 dans le protocole HTTP request entity-body :

• grant_type
  OBLIGATOIRE. La valeur DOIT être définie sur "password".
• username
  OBLIGATOIRE. Le nom d'utilisateur du propriétaire de la ressource.
• password
  OBLIGATOIRE. Le mot de passe du propriétaire de la ressource.
• scope (portée)
  OPTIONNEL. La portée de la demande d'accès telle que décrite par la section 3.3 .

Si le type de client est confidentiel ou si le client a été émis client informations d'identification (ou d'autres exigences d'authentification assignées), le client DOIT s'authentifier auprès du serveur d'autorisation comme décrit dans la section 3.2.1 .

Par exemple, le client effectue la requête HTTP suivante en utilisant la sécurité de la couche de transport (avec des sauts de ligne supplémentaires à des fins d'affichage uniquement) :

Script avec 6 lignes

001POST /token HTTP/1.1
002Host: server.example.com
003Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
004Content-Type: application/x-www-form-urlencoded
005
006grant_type=password&username=johndoe&password=A3ddj3w

Retirer les numéros de lignes

Le serveur d'autorisation DOIT :

• exiger l'authentification du client pour les clients confidentiels ou pour tout client qui a reçu des informations d'identification client (ou avec d'autres exigences d'authentification),
• authentifier le client si l'authentification client est incluse, et
• valider les identifiants du mot de passe du propriétaire de la ressource à l'aide de son algorithme de validation de mot de passe existant.

Étant donné que cette demande de jeton d'accès (access token) utilise le mot de passe du propriétaire de la ressource, le serveur d'autorisation DOIT protéger le point de terminaison contre attaques par force brute (par exemple, en utilisant la limitation du débit ou en générant alertes).

RFC 6749 - 4.3.3. Réponse du jeton d'accès (Access Token Request)

Si la demande de jeton d'accès est valide et autorisée, le serveur d'autorisation émet un jeton d'accès et une actualisation facultative jeton comme décrit dans la section 5.1 . Si la demande a échoué client authentification ou est invalide, le serveur d'autorisation renvoie un réponse d'erreur comme décrit dans la section 5.2 .

Exemple de réponse réussie :

Script avec 12 lignes

001HTTP/1.1 200 OK
002Content-Type: application/json;charset=UTF-8
003Cache-Control: no-store
004Pragma: no-cache
005
006{
007  "access_token":"2YotnFZFEjr1zCsicMWpAA",
008  "token_type":"example",
009  "expires_in":3600,
010  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
011  "example_parameter":"example_value"
012}

Retirer les numéros de lignes

RFC 6749 - 4.4. Octroi (attribution) des informations d'identification du client (Client Credentials Grant)

Le client peut demander un jeton d'accès en utilisant uniquement son client informations d'identification (ou d'autres moyens d'authentification pris en charge) lorsque le client demande l'accès aux ressources protégées sous son contrôle, ou ceux d'un autre propriétaire de la ressource qui ont été précédemment arrangé avec le serveur d'autorisation (dont la méthode est au-delà la portée de cette spécification).

Le type d'octroi (attribution) d'informations d'identification client DOIT être utilisé uniquement par des clients confidentiels.

Script avec 8 lignes

001Figure 6: Flux d'informations d'identification du client (Client Credentials Flow)
002+---------+                                  +---------------+
003|         |                                  |               |
004|         |>--(A)- Client Authentication --->| Authorization |
005| Client  |                                  |     Server    |
006|         |<--(B)---- Access Token ---------<|               |
007|         |                                  |               |
008+---------+                                  +---------------+

Retirer les numéros de lignes

Le flux illustré à la figure 6 comprend les étapes suivantes :

• (A) Le client s'authentifie auprès du serveur d'autorisation et demande un jeton d'accès au point de terminaison du jeton.
• (B) Le serveur d'autorisation authentifie le client et, s'il est valide, émet un jeton d'accès.

RFC 6749 - 4.4.1. Demande d'autorisation et réponse (Authorization Request and Response)

Étant donné que l'authentification du client est utilisée comme octroi (attribution) d'autorisation, aucune demande d'autorisation supplémentaire n'est nécessaire.

RFC 6749 - 4.4.2. Demande de jeton d'accès (Access Token Request)

Le client fait une demande au point de terminaison du jeton en ajoutant le paramètres suivants en utilisant le "application/x-www-form-urlencoded" format selon l'annexe B avec un codage de caractères UTF-8 dans le protocole HTTP request entity-body :

• grant_type
  OBLIGATOIRE. La valeur DOIT être définie sur "client_credentials".
• scope (portée)
  OPTIONNEL. La portée de la demande d'accès telle que décrite par Section 3.3 .

Le client DOIT s'authentifier auprès du serveur d'autorisation comme décrit à la section 3.2.1 .

Par exemple, le client effectue la requête HTTP suivante en utilisant la sécurité de la couche de transport (avec des sauts de ligne supplémentaires à des fins d'affichage uniquement) :

Script avec 6 lignes

001POST /token HTTP/1.1
002Host: server.example.com
003Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
004Content-Type: application/x-www-form-urlencoded
005
006grant_type=client_credentials

Retirer les numéros de lignes

Le serveur d'autorisation DOIT authentifier le client.

RFC 6749 - 4.4.3. Réponse du jeton d'accès (Access Token Response)

Si la demande de jeton d'accès est valide et autorisée, le serveur d'autorisation émet un jeton d'accès comme décrit dans la section 5.1 . Un jeton de rafraîchissement NE DEVRAIT PAS être inclus. Si la demande l'authentification du client a échoué ou n'est pas valide, le serveur d'autorisation renvoie une réponse d'erreur comme décrit dans la section 5.2 .

Exemple de réponse réussie :

Script avec 11 lignes

001HTTP/1.1 200 OK
002Content-Type: application/json;charset=UTF-8
003Cache-Control: no-store
004Pragma: no-cache
005
006{
007  "access_token":"2YotnFZFEjr1zCsicMWpAA",
008  "token_type":"example",
009  "expires_in":3600,
010  "example_parameter":"example_value"
011}

Retirer les numéros de lignes

RFC 6749 - 4.5. Octroi (Attribution) de prolongation (Extension Grants)

Le client utilise un type d'octroi d'extension en spécifiant le type d'octroi en utilisant un URI absolu (défini par le serveur d'autorisation) comme valeur du paramètre "grant_type" du point de terminaison du jeton, et par en ajoutant tous les paramètres supplémentaires nécessaires.

.......... ..................





---

Lire la suite ici ;) https://datatracker.ietf.org/doc/html/rfc6749.html + VS ^^ la traduction FRançaise ;)

---