TOC

Une introduction à OAuth 2

introduction

OAuth 2 est un cadre d’autorisation permettant aux applications d’obtenir un accès limité aux comptes d’utilisateur sur un service HTTP, tel que Facebook, GitHub et DigitalOcean. Cela fonctionne en déléguant l’authentification d’utilisateur au service qui héberge le compte d’utilisateur et en autorisant les applications tierces à accéder au compte d’utilisateur. OAuth 2 fournit des flux d’autorisation pour les applications Web et de bureau, ainsi que pour les appareils mobiles.

Ce guide d’information est destiné aux développeurs d’applications et fournit une vue d’ensemble des rôles, des types d’octroi d’autorisations, des cas d’utilisation et des flux OAuth 2.

Commençons avec OAuth Roles!

Rôles OAuth

OAuth définit quatre rôles:

  • Propriétaire de la ressource

  • Client

  • Serveur de ressources

  • Serveur d’autorisation

Nous détaillerons chaque rôle dans les sous-sections suivantes.

Propriétaire de la ressource: Utilisateur

Le propriétaire de la ressource est l’utilisateur qui autorise une application à accéder à son compte. L’accès de l’application au compte de l’utilisateur est limité à la «portée» de l’autorisation octroyée (par exemple, accès en lecture ou en écriture).

Serveur de ressources / d’autorisations: API

Le serveur de ressources héberge les comptes d’utilisateurs protégés et le serveur d’autorisations vérifie l’identité de l’utilisateur user, puis émet des jetons d’accès à l’application application.

Du point de vue des développeurs d’applications, la * API * d’un service remplit à la fois les rôles de serveur de ressources et d’autorisation. Nous ferons référence à ces deux rôles combinés, en tant que rôle Service ou API.

Client: Application

Le client est l’application qui veut accéder au compte de l’utilisateur. Avant de pouvoir le faire, il doit être autorisé par l’utilisateur et l’autorisation doit être validée par l’API.

Flux de protocole abstrait

Maintenant que vous avez une idée des rôles OAuth, voyons un diagramme illustrant la manière dont ils interagissent en général:

image: https: //assets.digitalocean.com/articles/oauth/abstract_flow.png [Déroulement du protocole abstrait]

Voici une explication plus détaillée des étapes du diagramme:

  1. Application demande l’autorisation d’accéder aux ressources du service à partir de user

  2. Si l’utilisateur a autorisé la demande, l’application reçoit une autorisation

  3. Application demande un jeton d’accès au authorization server (API) en présentant l’authentification de sa propre identité et l’autorisation

  4. Si l’identité de l’application est authentifiée et que l’autorisation d’autorisation est valide, l’Autorité serveur_autorisation (API) émet un jeton d’accès à l’application. L’autorisation est terminée.

  5. Application demande la ressource au serveur de ressources _ (API) et présente le jeton d’accès pour l’authentification.

  6. Si le jeton d’accès est valide, le serveur de ressource _ (API) fournit la ressource à l’application _

Le flux réel de ce processus diffère en fonction du type d’octroi d’autorisation utilisé, mais c’est l’idée générale. Nous explorerons différents types de subventions dans une section ultérieure.

Enregistrement d’application

Avant d’utiliser OAuth avec votre application, vous devez enregistrer votre application auprès du service. Cela se fait via un formulaire d’inscription dans la partie "développeur" ou "API" du site Web du service, où vous fournirez les informations suivantes (et probablement des détails sur votre application):

  • Nom de l’application

  • Site d’application

  • URL de redirection ou URL de rappel

L’URI de redirection est l’endroit où le service redirigera l’utilisateur une fois qu’il aura autorisé (ou refusé) votre application, et donc la partie de votre application qui gérera les codes d’autorisation ou les jetons d’accès.

Identifiant client et secret client

Une fois votre application enregistrée, le service émettra des «informations d’identification du client» sous la forme d’un identifiant de client et d’un secret de client. L’ID client est une chaîne exposée publiquement utilisée par l’API de service pour identifier l’application, mais également pour créer des URL d’autorisation présentées aux utilisateurs. Le secret client est utilisé pour authentifier l’identité de l’application auprès de l’API du service lorsque celle-ci demande à accéder au compte d’un utilisateur. Il doit rester confidentiel entre l’application et l’API.

Autorisation Grant

Dans le flux de protocole d’abonnement ci-dessus, les quatre premières étapes concernent l’obtention d’une autorisation et d’un jeton d’accès. Le type d’attribution d’autorisation dépend de la méthode utilisée par l’application pour demander une autorisation et des types d’attribution pris en charge par l’API. OAuth 2 définit quatre types de subvention, chacun étant utile dans différents cas:

  • * Code d’autorisation *: utilisé avec les applications côté serveur

  • * Implicite *: utilisé avec les applications mobiles ou les applications Web (applications exécutées sur le terminal de l’utilisateur)

  • * Informations d’identification du mot de passe du propriétaire de la ressource *: utilisées avec des applications sécurisées, telles que celles appartenant au service lui-même

  • * Identifiants client *: utilisés avec l’accès API Applications

Nous allons maintenant décrire les types de subvention plus en détail, leurs cas d’utilisation et leurs flux, dans les sections suivantes.

Type de subvention: Code d’autorisation

Le type d’octroi * code d’autorisation * est le plus couramment utilisé car il est optimisé pour les applications côté serveur, où le code source n’est pas exposé publiquement, et la confidentialité de Client Secret peut être conservée. Il s’agit d’un flux basé sur la redirection, ce qui signifie que l’application doit être capable d’interagir avec user-agent (c.-à-d. navigateur Web de l’utilisateur) et la réception des codes d’autorisation de l’API acheminés via l’agent utilisateur.

Nous allons maintenant décrire le flux de code d’autorisation:

image: https: //assets.digitalocean.com/articles/oauth/auth_code_flow.png [Flux de codes d’autorisation]

Étape 1: Lien vers le code d’autorisation

Tout d’abord, l’utilisateur reçoit un lien de code d’autorisation qui ressemble à ce qui suit:

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=&redirect_uri=&scope=

Voici une explication des composants du lien:

  • * https: //cloud.digitalocean.com/v1/oauth/authorize*: le noeud final d’autorisation de l’API

  • * client_id = *: l’ID_client de l’application (comment l’API identifie l’application)

  • * redirect_uri = *: où le service redirige l’agent utilisateur après l’octroi d’un code d’autorisation

  • * response_type = *: indique que votre application demande une autorisation de code d’autorisation.

  • * scope = *: spécifie le niveau d’accès demandé par l’application

Étape 2: l’utilisateur autorise l’application

Lorsque l’utilisateur clique sur le lien, il doit d’abord se connecter au service pour authentifier son identité (à moins qu’il ne soit déjà connecté). Ensuite, ils seront invités par le service à authorize ou deny à accéder à leur compte par l’application. Voici un exemple d’invite d’autorisation d’application:

image: https: //assets.digitalocean.com/articles/oauth/authcode.png [Lien du code d’autorisation]

Cette capture d’écran particulière est celle de l’écran d’autorisation de DigitalOcean et nous pouvons voir que «Thedropletbook App» demande une autorisation pour un accès «en lecture» au compte «[email protected]».

Étape 3: le code d’autorisation est attribué à l’application.

Si l’utilisateur clique sur «Autoriser l’application», le service redirige l’agent utilisateur vers l’URI de redirection d’application, spécifié lors de l’enregistrement du client, accompagné d’un authorization code. La redirection ressemblerait à quelque chose comme ça (en supposant que l’application est "dropletbook.com"):

https://dropletbook.com/callback?code=

Étape 4: jeton d’accès aux demandes d’application

L’application demande un jeton d’accès à l’API, en transmettant le code d’autorisation ainsi que les détails de l’authentification, y compris client secret, au noeud final de jeton de l’API. Voici un exemple de requête POST adressée au noeud final de jeton de DigitalOcean:

https://cloud.digitalocean.com/v1/oauth/token?client_id=&client_secret=&grant_type=authorization_code&code=&redirect_uri=

Étape 5: l’application reçoit le jeton d’accès

Si l’autorisation est valide, l’API enverra une réponse contenant le jeton d’accès (et éventuellement un jeton d’actualisation) à l’application. La réponse entière ressemblera à quelque chose comme ceci:

{"access_token":"","token_type":"bearer","expires_in":2592000,"refresh_token":"","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"[email protected]"}}

Maintenant l’application est autorisée! Il peut utiliser le jeton pour accéder au compte de l’utilisateur via l’API de service, dans la limite de l’étendue de l’accès, jusqu’à l’expiration du jeton ou sa révocation. Si un jeton d’actualisation a été émis, il peut être utilisé pour demander de nouveaux jetons d’accès si le jeton d’origine a expiré.

Type de subvention: implicite

Le type de subvention * implicite * est utilisé pour les applications mobiles et les applications Web (c’est-à-dire applications exécutées dans un navigateur Web), où la confidentialité client secret n’est pas garantie. Le type d’attribution implicite est également un flux basé sur la redirection, mais le jeton d’accès est donné à l’agent utilisateur pour être transféré à l’application, de sorte qu’il peut être exposé à l’utilisateur et à d’autres applications sur le périphérique de l’utilisateur. En outre, ce flux n’authentifie pas l’identité de l’application et s’appuie sur l’URI de redirection (qui a été enregistré avec le service) pour atteindre cet objectif.

Le type d’accord implicite ne prend pas en charge les jetons d’actualisation.

Le flux d’octroi implicite fonctionne essentiellement comme suit: il est demandé à l’utilisateur d’autoriser l’application, puis le serveur d’autorisation renvoie le jeton d’accès à l’agent utilisateur, qui le transmet à l’application. Si vous êtes curieux de connaître les détails, lisez la suite.

image: https: //assets.digitalocean.com/articles/oauth/implicit_flow.png [Flux implicite]

Étape 1: Lien d’autorisation implicite

Avec le type d’attribution implicite, un lien d’autorisation est présenté à l’utilisateur, qui demande un jeton à l’API. Ce lien ressemble au lien de code d’autorisation, sauf qu’il demande un token au lieu d’un code (notez le response type “token”):

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=token&client_id=&redirect_uri=&scope=

Étape 2: l’utilisateur autorise l’application

Lorsque l’utilisateur clique sur le lien, il doit d’abord se connecter au service pour authentifier son identité (à moins qu’il ne soit déjà connecté). Ensuite, ils seront invités par le service à authorize ou deny à accéder à leur compte par l’application. Voici un exemple d’invite d’autorisation d’application:

image: https: //assets.digitalocean.com/articles/oauth/authcode.png [Lien du code d’autorisation]

Nous pouvons voir que «Thedropletbook App» demande une autorisation pour un accès «en lecture» au compte «[email protected]».

Étape 3: l’agent utilisateur reçoit le jeton d’accès avec l’URI de redirection

Si l’utilisateur clique sur «Autoriser l’application», le service redirige l’agent utilisateur vers l’URI de redirection d’application et inclut un fragment d’URI contenant le jeton d’accès. Cela ressemblerait à ceci:

https://dropletbook.com/callback#token=

Étape 4: L’agent utilisateur suit l’URI de redirection

L’agent utilisateur suit l’URI de redirection mais conserve le jeton d’accès.

Étape 5: l’application envoie un script d’extraction de jeton d’accès

L’application renvoie une page Web contenant un script permettant d’extraire le jeton d’accès à partir de l’URI de redirection complète que l’agent utilisateur a conservé.

Étape 6: jeton d’accès transmis à l’application

L’agent d’utilisateur exécute le script fourni et transmet le jeton d’accès extrait à l’application.

Maintenant l’application est autorisée! Il peut utiliser le jeton pour accéder au compte de l’utilisateur via l’API de service, dans la limite de l’étendue de l’accès, jusqu’à l’expiration du jeton ou sa révocation.

Type de subvention: Informations d’identification du mot de passe du propriétaire de la ressource

Avec le type d’octroi * des informations d’identification du mot de passe du propriétaire de la ressource *, l’utilisateur fournit ses informations d’identification de service (nom d’utilisateur et mot de passe) directement à l’application, qui les utilise pour obtenir un jeton d’accès à partir du service. Ce type de subvention ne doit être activé sur le serveur d’autorisation que si d’autres flux ne sont pas viables. De plus, il ne devrait être utilisé que si l’application est approuvée par l’utilisateur (par exemple, il appartient au service ou au système d’exploitation de l’utilisateur).

Flux d’informations d’identification de mot de passe

Une fois que l’utilisateur a fourni ses informations d’identification à l’application, celle-ci demande alors un jeton d’accès au serveur d’autorisation. La demande POST pourrait ressembler à quelque chose comme ceci:

https://oauth.example.com/token?grant_type=password&username=&password=&client_id=

Si les informations d’identification de l’utilisateur sont extraites, le serveur d’autorisations renvoie un jeton d’accès à l’application. Maintenant l’application est autorisée!

  • Remarque: * DigitalOcean ne prenant pas en charge le type d’octroi d’informations d’identification de mot de passe, le lien pointe donc vers un serveur d’autorisation imaginaire situé à l’adresse «oauth.example.com».

Type de subvention: Informations d’identification du client

Le type d’octroi * informations d’identification client * fournit à une application un moyen d’accéder à son propre compte de service. Cela peut être utile, par exemple, si une application souhaite mettre à jour sa description enregistrée ou rediriger l’URI, ou accéder à d’autres données stockées dans son compte de service via l’API.

Flux d’informations d’identification du client

L’application demande un jeton d’accès en envoyant ses informations d’identification, son ID client et son secret client au serveur d’autorisation. Un exemple de demande POST pourrait ressembler à ceci:

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Si les informations d’identification de l’application sont extraites, le serveur d’autorisations renvoie un jeton d’accès à l’application. Maintenant, l’application est autorisée à utiliser son propre compte!

  • Remarque: * DigitalOcean ne prenant pas en charge le type d’octroi d’informations d’identification du client, le lien pointe vers un serveur d’autorisations imaginaire situé à l’adresse «oauth.example.com».

Exemple d’utilisation de jeton d’accès

Une fois que l’application dispose d’un jeton d’accès, elle peut utiliser ce jeton pour accéder au compte de l’utilisateur via l’API, dans la limite de l’étendue de l’accès, jusqu’à ce que le jeton expire ou soit révoqué.

Voici un exemple de requête d’API, utilisant + curl +. Notez qu’il inclut le jeton d’accès:

curl -X POST -H "Authorization: Bearer ""https://api.digitalocean.com/v2/"

En supposant que le jeton d’accès soit valide, l’API traitera la demande en fonction de ses spécifications d’API. Si le jeton d’accès a expiré ou est invalide, l’API renvoie une erreur «invalid_request».

Actualiser le flux de jetons

Après l’expiration d’un jeton d’accès, son utilisation pour faire une demande à partir de l’API entraînera une «erreur de jeton invalide». À ce stade, si un jeton d’actualisation était inclus lors de l’émission du jeton d’accès d’origine, il peut être utilisé pour demander un nouveau jeton d’accès au serveur d’autorisation.

Voici un exemple de demande POST, utilisant un jeton d’actualisation pour obtenir un nouveau jeton d’accès:

https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=&client_secret=&refresh_token=

Conclusion

Ceci conclut ce guide OAuth 2. Vous devriez maintenant avoir une bonne idée du fonctionnement d’OAuth 2 et du moment où un flux d’autorisations particulier doit être utilisé.

Si vous souhaitez en savoir plus sur OAuth 2, consultez ces précieuses ressources:

Related