OAuth 2.0 and OpenID Connect Flows

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 or response_type=id_token
• Hybrid Flow - response_type=code id_token, response_type=code token or response_type=code id_token token

In actuality, these all work in the exact same way:

• If response_type contains code then generate and return an Authorization Code that can be exchanged for an Access Token
  • In this case, if scope contains openid then include an ID Token as well as an Access Token in the response from the Token endpoint.
• If response_type contains token 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 contains id_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 not code. 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.

Am I missing anything here? Or is it really that this simpler interpretation gives everything needed from the spec?