Accueil > OpenID Connect OAuth Server par DnC > Développer > OpenID Connect > OpenID Connect : Synthèse des flux d’autorisation (Grant Type)

OpenID Connect : Synthèse des flux d’autorisation (Grant Type)

Les tableaux de cet article synthétisent les flux offerts par OpenID Connect et la couche sous-jacente OAuth 2.0. Il permet de naviguer vers les têtes de chapitres correspondantes de la documentation.

La plupart des fonctionnalités d’OAuth 2.0 sont intégrées au protocole OpenID Connect. Les fonctionnalités d’OAuth 2.0 et de OpenID Connect peuvent donc être atteintes par les Points d’extrémité d’OpenID Connect [1].

Type de flux selon les paramètres de l’appel à Authorize

1. Requêtes adressées au point d’extrémité authorize. Les différentes valeurs du paramètre response_type (obligatoire) et du scope openid (facultatif) déterminent les flux d’autorisation (Grant Type) suivants :

Grant Type response_type openid Rem.
OAuth 2.0 Authorization Code code N RFC 6749
OIDC Authorization Code code Y
OAuth 2.0 Implicit token X [2] RFC 6749
OIDC Implicit id_token, id_token token Y [3] OpenID Connect Implicit Client. ’nonce’ est requis.
OIDC Hybrid code id_token Y ’c_hash’ est requis
Hybrid code token X Invalid [4]
Hybrid code id_token token Y Invalid [4]

Références :
- The OAuth 2.0 Authorization Framework.
- OpenID Connect Core 1.0 incorporating errata set 1 : Authentication using the Hybrid Flow.


Notes :
- A propos des response type "id_token" et "id_token token" :
ces types de réponse correspondent à des flux implicites retournant directement les jetons. Le paramètre "nonce" doit être présent dans la requête.

- A propos des response type "code token" et "code token-id token" :
ces types de réponse correspondent à des flux hybrides retournant directement le ou les jetons. OAuthSD est fondé sur la librairie OAuth 2.0 Server PHP développée par Brent Shaffer. Dans le cadre d’OpenID Connect, celle-ci n’accepte que la demande de flux hybride "code id_token".


2. Requêtes adressées directement au point d’extrémité token. Ces flux ne sont définis que par OAuth 2.0 et ne retournent pas de jeton d’identité, que le scope openid soit indiqué ou non.

Grant Type grant_type Access Token Refresh Token Rem.
Client Credentials client_credentials Y Y  [5]
User Credentials [6] password Y N
JWT Bearer - Y N  [7]

References :
- RFC 6749 Client Credentials Grant,
- Spécification draft-ietf-oauth-jwt-bearer-07 section 1

Synthèse des fonctionnalités offertes par les différents flux OpenID Connect

Voir : https://openid.net/specs/openid-connect-core-1_0.html#Authentication

Propriété Flux de codes d’autorisation Flux implicite Flux hybride
Tous les jetons renvoyés depuis le contrôleur Authorization non oui non
Tous les jetons renvoyés par le contrôleur Token oui non non
Jetons non révélés à l’agent utilisateur oui non non
Le client peut être authentifié [8] oui non oui
Actualisation du jeton d’accès possible oui non oui
Communication en un aller-retour non oui non
La plupart des communications serveur à serveur oui non varie

Choix du flux en fonction de la configuration

Tous les flux n’ont pas la même valeur pour la protection des données confidentielles.
Avant de choisir un flux OpenID Connect, il est important d’identifier la configuration des parties prenantes (applications, serveur OIDC, serveurs de ressource etc.).

Cette problématique est exposée ici : Typologie des applications au regard de la sécurité des données.

Notes

[1Même si les points de terminaison de OAuth 2.0 peuvent être adressés spécifiquement sur le serveur OAuthSD aux URLs https://oa.dnc.global/oauth/...

[2Que le scope openid soit fourni ou non, ce flux Implicite ne retourne pas de jeton d’Identité.

[3Que le scope openid soit fourni ou non, ce flux retourne toujours le jeton d’Identité.

[4Non encore implémenté dans l’état actuel du développement de la librairie OAuth 2.0 Server PHP.

[5Ce flux ne fournit pas le jeton d’actualisation. Voir : http://tools.ietf.org/html/rfc6749#section-4.4.3

[6Ou "Resource Owner Password Credentials Grant Type". Nous citons ce flux, et OAuthSD le met en oeuvre, uniquement par souci de complétude. Ce flux ne doit pas être considéré comme une authentification ; au contraire, l’utilisation de ce flux conduit à une impersonnisation (sur ce sujet, voir : https://www.scottbrady91.com/OAuth/..., nous recommendons donc de ne pas l’utiliser.

[7Cela ressemble beaucoup à l’échange de jeton décrit ici : Un jeton d’identification peut être utilisé pour ... et par cette proposition de standard : Draft IETF : Token Exchange.

[8C’est là l’essence même d’OpenID Connect. Le flux Authorization Code fournit un jeton JWT qui, par sa signature, lie le client, l’utilisateur final et la portée de l’autorisation.