Accueil > OpenID Connect OAuth Server dedicated > OpenID Connect : Summary of all authorization flows

OpenID Connect : Summary of all authorization flows

The tables in this article summarize the flows offered by OpenID Connect and the underlying layer OAuth 2.0. It allows you to navigate to the corresponding chapters in the documentation.

Most of the features of OAuth 2.0 are integrated into the OpenID Connect protocol. Features of OAuth 2.0 and OpenID Connect can therefore be reached by OpenID Connect Endpoints [1].

Flow type according to the parameters of the call

1. Requests addressed to authorize endpoint. The different values of parameter_type (required) and scope openid (optional) determine the following Grant Type flows :

Grant Type response_type openid Obs.
OAuth 2.0 Authorization Code code N RFC 6749
OIDC Authorization Code code Y
OIDC Implicit id_token, id_token token Y OpenID Connect Implicit Client. "nonce" required
OAuth 2.0 implicit token X [2]  [3]
Hybrid code id_token Y "c_hash" required
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 :
- About the response type "id_token" and "id_token token" :
these response types correspond to implicit flows that directly return the tokens. The "nonce" parameter must be present in the request.

- About response type "token code" and "token-id token code" :
these response types correspond to hybrid flows that directly return the token(s). OAuthSD is based on the OAuth 2.0 Server PHP library developed by Brent Shaffer. As part of OpenID Connect, it accepts only the hybrid flow request with the "code id_token" response type.


2. Queries sent directly to the token endpoint. These flows are only defined by OAuth 2.0 and do not return an identity token, whether or not the openid scope is specified.

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

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


Summary of the features offered by the different OpenID Connect flows

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

Property Authorization Code Flow Implicit Flow Hybrid Flow
All tokens returned from Authorization Endpoint no yes no
All tokens returned from Token Endpoint yes no no
Tokens not revealed to User Agent yes no no
Client can be authenticated yes no yes
Refresh Token possible yes no yes
Communication in one round trip no yes no
Most communication server-to-server yes no varies

Choose the flow based on the configuration

Not all flows have the same value for the protection of confidential data.
Before choosing an OpenID Connect feed, it is important to identify the configuration of the parties (applications, OIDC server, resource servers, etc.).

This problem is explained here : Typologie des applications au regard de la sécurité des données.

Notes

[1Although OAuth 2.0 endpoints can be addressed specifically to the OAuthSD server at URLs https: //oa.dnc.global/oauth / ...

[2Whether the openid scope is provided or not, this Implicit stream does not return an Identity token.

[3Unidentified flow of type Implicit to which the server responds.

[4Not yet implemented in the current state of development of the libraryOAuth 2.0 Server PHP.

[5Does NOT include a refresh token, see : http://tools.ietf.org/html/rfc6749#section-4.4.3

[6Or "Resource Owner Password Credentials Grant Type". We quote this stream, and OAuthSD implements it, only for the sake of completeness. This stream should not be considered as an authentication ; on the contrary, the use of this flow leads to an impersonation (on this subject, see : https://www.scottbrady91.com/OAuth/..., we therefore recommend not to use it.

[7This is very similar to the token exchange described here : Un jeton d’identité peut être utilisé pour ... and by this proposal of standard : Draft IETF : Token Exchange.