OpenID Connect Flows - An expressive formal model of the web infrastructure

OIDC defines three flows: the authorization code flow, the implicit flow, and the hybrid flow. The first two are directly based on the respective OAuth grants. In the authorization code flow, the id token is retrieved by an RP from an OP in direct server-to-server communication (sometimes called back channel ), and in the implicit flow, the id token is relayed from an OP to an RP via the user’s browser (also called front channel ). The hybrid flow is a combination of both flows and allows id tokens to be exchanged via the front and the back channel at the same time. We now provide a detailed description of all three flows.

4.3.1. Authorization Code Flow

In this flow, an RP redirects the user’s browser to an OP. At the OP, the user authenticates herself and then the OP issues an authorization code to the RP. The RP now uses this authorization code to obtain an id token (and, optionally, an access token) from the OP.

Step-by-Step Protocol Flow

First, the Discovery and Dynamic Registration protocols, as presented above, are executed (if needed). Then, the core part of the OpenID Connect protocol starts (depicted in Figure4.3):

– The RP redirects the user’s browser to the OP 10 _{. This redirect contains the information}

that the authorization code flow is used, the client id of the RP, a redirect URI, and a state value. The redirect may also optionally include a nonce, which will be included in the id token issued later in this flow.

– This data is sent to the OP by the browser 11_.

– The user authenticates to the OP 12 _, 13_{, and the OP redirects the user’s browser back}

to the RP 14_, 15 _{. The OP uses the redirect URI from the request in Step} 11_{. The}

redirect contains an authorization code, the state value received in Step 10_{, and the issuer}

identifier.2

– If the state value and the issuer identifier are correct, the RP contacts the OP at the token endpoint with the received authorization code, its client id, its client secret (if any), and the redirect URI used to obtain the authorization code 16 _.

– The OP sends a response with a fresh access token and an id token to the RP 17 _.

– If the id token is valid, the RP considers the user to be logged in under the identifier composed from the user id in the id token and the issuer identifier. Hence, the RP may set a session cookie at the user’s browser 18 _{. Optionally, the RP can use the access token}

to access the user’s resources at some RS.

4.3.2. Implicit Flow

This flow is similar to the authorization code flow, but instead of providing an authorization code, the OP issues an id token right away to the RP (via the user’s browser) when the user authenticates to the OP.

Step-by-Step Protocol Flow

The protocol flow is depicted in Figure 4.4. The implicit flow differs only in its last part from the authorization code flow, i.e., the Steps 10_– 13 _{of the authorization code flow (Figure}_4.3₎

are the same, with the exception that the nonce is mandatory in the implicit flow.

As already mentioned above, the OP does not issue an authorization code in Step 14 _(Fig-

ure 4.4). Instead, the OP redirects the user’s browser to the redirection endpoint at the RP, providing an id token, optionally an access token, the state value (as received in Step 11_),

and the issuer identifier. These values are not provided as a URL parameter but in the URL 2_{The issuer identifier is included here as a fix against the AS Mix-Up attack, cf. Section}_3.3.2_.

1 POST /startPOST /start

Discovery and Registration (as above)

10 ResponseResponse

Redirect to OP authEP with client id , redirect uri , state, nonce

11 GET authEPGET authEP

client id , redirect uri , state, nonce

12 ResponseResponse

13 POST /authPOST /auth

username, password

14 ResponseResponse

Redirect to RP redirect uri with issuer , fragment: id token, access token, state,

15 GET redirect uriGET redirect uri

issuer

16 ResponseResponse

17 POST /tokenPOST /token

issuer , id token, access token, state

18 ResponseResponse

session cookie

º Browser RP OP

Figure 4.4. OpenID Connect implicit flow.

fragment instead, as in the OAuth implicit grant. Hence, the browser does not send them to the RP at first. Instead, the RP has to provide a JavaScript that retrieves these values from the fragment and sends them to the RP. If the id token is valid, the issuer is correct, and the state matches the one chosen by the RP for Step 10_{, the RP considers the user to be logged in}

and issues a session cookie.

4.3.3. Hybrid Flow

The hybrid flow (depicted in Figure 4.5) is a combination of the authorization code flow and the implicit flow: First, it works like the implicit flow, but when OP redirects the browser back to RP (Step 14_{), the OP issues an authorization code, and either an id token or an access}

token or both.3 The RP then retrieves these values as in the implicit flow (as they are sent in the fragment like in the implicit flow) and uses the authorization code to obtain a (potentially second) id token and a (potentially second) access token from OP (Steps 18_f.).

The choice of the OP to issue either an id token or an access token or both depends on the OP’s configuration and the request in Step 11 in Figure4.5.

1 POST /startPOST /start

Discovery and Registration (as above)

10 ResponseResponse

Redirect to OP authEP with client id , redirect uri , state, (nonce)

11 GET authEPGET authEP

client id , redirect uri , state, (nonce)

12 ResponseResponse

13 POST /authPOST /auth

username, password

14 ResponseResponse

Redirect to RP redirect uri , fragment: code, [id token and/or access token], state

15 GET redirect uriGET redirect uri

16 ResponseResponse

17 POST /tokenPOST /token

code, [id token and/or access token], state

18 POST tokenEPPOST tokenEP

code, client id , redirect uri , (client secret )

19 ResponseResponse

access token0, id token

20 ResponseResponse

session cookie

º Browser RP OP

Figure 4.5. OpenID Connect hybrid flow.

In document An expressive formal model of the web infrastructure (Page 101-104)