Octroi d'autorisation OAuth 2.0 (OAuth 2.0 grant)

Qu’est-ce qu’un octroi d’autorisation OAuth 2.0 ?

Un octroi d’autorisation OAuth 2.0 est un processus d’autorisation qui permet à un Client de demander un Jeton d'accès (Access token) à un Serveur d'autorisation (Authorization server) . Vous pouvez également entendre d’autres termes autour de ce concept, clarifions-les avant d’approfondir :

• Octroi d’autorisation OAuth 2.0: Également connu sous le nom de “type d’autorisation OAuth 2.0”, “flux OAuth 2.0”, ou “octroi d’autorisation OAuth 2.0”. Dans la plupart des contextes, ces termes se réfèrent au même concept.
• Serveur d'autorisation (Authorization server) : Le serveur qui émet des access tokens à un client. Dans OpenID Connect (OIDC), le serveur d’autorisation est le même que le OpenID Provider (OP) .
• Demande d'autorisation (Authorization request) : La demande faite par le client au serveur d’autorisation pour obtenir un access token. Dans OpenID Connect (OIDC), cela est également appelé une Requête d'authentification (Authentication request) .

Pour plus de clarté, nous utiliserons systématiquement les termes initiaux énumérés ci-dessus tout au long de cet article.

Le processus d’un octroi d’autorisation OAuth 2.0 est assez simple :

Après que le client a reçu le access token, il peut l’utiliser pour accéder à des ressources protégées (par exemple, des API) pour le compte d’un utilisateur ou en son propre nom.

Notez que selon l’octroi spécifique, le client et le serveur d’autorisation peuvent échanger des informations supplémentaires et impliquer plus d’étapes dans le processus. Par exemple, l’ octroi du code d’autorisation implique l’authentification et l’autorisation de l’utilisateur, la génération de code et l’échange de token.

Différents octrois d’autorisation OAuth 2.0

La spécification de base d’OAuth 2.0 définit quatre octrois que les clients peuvent utiliser pour obtenir des access tokens :

1. Octroi du code d’autorisation : L’octroi le plus sécurisé et recommandé pour la majorité des applications. Il est imposé d’utiliser Clé de preuve pour l'échange de code (Proof Key for Code Exchange, PKCE) pour tous les clients dans OAuth 2.1 .
2. Octroi implicite : Un octroi simplifié qui est déprécié dans OAuth 2.1 en raison de préoccupations de sécurité.
3. Octroi des informations d’identification du propriétaire de la ressource (ROPC) : Un octroi où les informations d’identification de l’utilisateur sont directement échangées contre un access token. Il n’est pas recommandé pour la plupart des applications en raison des risques de sécurité.
4. Octroi des informations d’identification du client : Un octroi utilisé par un Clients confidentiels pour obtenir un access token sans implication de l’utilisateur.

À mesure que l’industrie évolue, les octrois implicites et ROPC sont en train d’être dépréciés au profit de flux plus sécurisés et standardisés. Pour les nouvelles applications, les choix sont simples :

• Pour l’authentification et l’autorisation des utilisateurs, utilisez l’octroi du code d’autorisation avec PKCE.
• Pour la communication Machine-to-machine , utilisez l’octroi des informations d’identification du client.

Autres octrois d’autorisation OAuth 2.0

En plus des quatre octrois de base, il existe d’autres extensions qui définissent de nouveaux octrois pour des cas d’utilisation spécifiques. Par exemple :

• Octroi d’autorisation d’appareil est un octroi conçu pour les appareils avec des capacités d’entrée limitées, tels que les téléviseurs intelligents et les périphériques IoT.
• Flux hybride est un octroi OpenID Connect qui combine l’octroi du code d’autorisation avec l’octroi implicite.

Octrois dans OpenID Connect (OIDC)

Dans OpenID Connect (OIDC) , le concept d’octrois est étendu pour inclure des ID tokens qui représentent des informations d’identité utilisateur en plus des access tokens. OIDC étend deux octrois OAuth 2.0 (code d’autorisation et implicite) pour inclure des ID tokens, et introduit un nouvel octroi appelé flux hybride qui combine les deux.

Comme OAuth 2.0, il est seulement recommandé d’utiliser l’octroi du code d’autorisation avec PKCE dans OIDC pour l’authentification et l’autorisation des utilisateurs.

Pendant ce temps, puisque OIDC est construit sur OAuth 2.0, d’autres octrois comme l’octroi des informations d’identification du client peuvent toujours être utilisés sur le même serveur d’autorisation, tant que le serveur les prend en charge.

Voir aussi

• Clé de preuve pour l'échange de code (Proof Key for Code Exchange, PKCE)
• OAuth 2.1
• Flux du code d'autorisation (Authorization code flow)
• Flux implicite (Implicit flow)
• Flux d'informations d'identification client (Client credentials flow)
• Flux de périphérique (Device flow)