OAuth 2.0 and OpenID Connect Flows

June 05, 2018 0 Comments

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 - responsetype=code

  • OAuth 2.0 Implicit Grant - responsetype=token

OpenID Connect then augments these with the following:

  • OIDC Implicit Grant - responsetype=idtoken token or responsetype=idtoken

  • Hybrid Flow - responsetype=code idtoken, responsetype=code token or responsetype=code idtoken token

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

  • If responsetype 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 responsetype 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 responsetype contains idtoken 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 idtoken

  • token code

  • idtoken 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

  • responsetype - always REQUIRED

  • clientid - always REQUIRED

  • redirecturi - always REQUIRED

  • state - always RECOMMENDED

  • nonce - REQUIRED if responsetype contains idtoken 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?

Tag cloud