Graham Cox
Posted on June 4, 2018
This post is partly for my own benefit, and partly for people to tell me that I've completely misunderstood things. So please, if it's wrong then tell me!
OAuth 2.0 offers two standard flows:
- Authorization Code Grant -
response_type=code
- OAuth 2.0 Implicit Grant -
response_type=token
OpenID Connect then augments these with the following:
- OIDC Implicit Grant -
response_type=id_token token
orresponse_type=id_token
- Hybrid Flow -
response_type=code id_token
,response_type=code token
orresponse_type=code id_token token
In actuality, these all work in the exact same way:
- If
response_type
containscode
then generate and return an Authorization Code that can be exchanged for an Access Token- In this case, if
scope
containsopenid
then include an ID Token as well as an Access Token in the response from the Token endpoint.
- In this case, if
- If
response_type
containstoken
then generate and return an Access Token - though probably a more tightly restricted one that expires sooner.- In this case, return the parameters as a Fragment on the redirect. If this is not present then return the parameters as a Querystring instead.
- If
response_type
containsid_token
then generate and return an ID Token.
These three rules can then be mixed and matched however is wished to give the combinations that are covered in the spec.
However, interestingly enough, if you follow these three rules instead then you get more flexibility. For example, the specs allow for all 7 combinations but only in a specific ordering - which happens to be alphabetical. Ignoring that fact would allow you to also accept:
- code token id_token
- token code
- id_token code token
- etc
I don't see that there's a whole lot of benefit to this, but the flexibility that you gain by making the rules simpler seems to be of some use.
Additionally, the rules for mandatory inputs are apparently that:
- scope - always REQUIRED
- response_type - always REQUIRED
- client_id - always REQUIRED
- redirect_uri - always REQUIRED
- state - always RECOMMENDED
- nonce - REQUIRED if response_type contains
id_token
but notcode
. OPTIONAL otherwise.- I don't get this one, but the OpenID Connect specification explicitly marks
nonce
as REQUIRED only during the OIDC Implicit Flow, and not in the others.
- I don't get this one, but the OpenID Connect specification explicitly marks
Am I missing anything here? Or is it really that this simpler interpretation gives everything needed from the spec?
Posted on June 4, 2018
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.