Accueil > OpenID Connect OAuth Serveur dédié > OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant (...)

OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type) Une approche Systémique d’OAuthSD

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.

Pour une approche des fonctionnalités d’OAuthSD par les points d’entrée (Endpoints), voyez OpenID Connect et OAuth 2.0 : Les points d’entrée d’OAuthSD .

OAuthSD intègre la plupart des fonctionnalités d’OAuth 2.0. Les fonctionnalités d’OAuth 2.0 et de OpenID Connect peuvent être atteintes par les Points d’extrémité d’OpenID Connect.

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

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 Non RFC 6749
OIDC Authorization Code code Oui
OAuth 2.0 Implicit token X [1] RFC 6749
OIDC Implicit id_token, id_token token Oui [2] OpenID Connect Implicit Client. ’nonce’ est requis.
OIDC Hybrid code id_token Oui ’c_hash’ est requis
Hybrid code token X Invalid [3]
Hybrid code id_token token Oui 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 en même temps que le code d’autorisation. 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 Oui Oui  [4]
User Credentials [5] password Oui Non
JWT Bearer - Oui Non  [6]

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é [7] 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.

Pour tester le serveur OAuthSD avec vos applications :
- Inscrivez-vous comme auteur d’applications
- Lier une application cliente au serveur OAuthSD

Notes

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

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

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

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

[5Ou "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.

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

[7C’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.