The Non-Orientability of OAuth

There’s a touch of the ouroboros in the OAuth ecosystem as well

Still life with Klein bottle. Author’s collection.

In certain mathematical spaces, if you have trouble “staying clockwise” as you traverse a surface, that means it’s non-orientable. Möbius strips and Klein bottles are good examples – as you go around, you flip to counterclockwise.

OAuth has an orientability problem, which I believe is why people struggle to explain it and its relationship with OpenID Connect.

A recent Hacker News post anchored on some OIDC news from identity standards O.G. Mike Jones got me thinking in these terms. It’s a meaty thread, and I recommend it if you’re looking for OAuth and OIDC history or a variety of explanatory materials that help get your head around them.

The challenge is that it’s so easy to get tangled up in authentication vs. authorization vs. delegation. Doesn’t authentication usually “come first” as a key source of signals on which to base an authorization decision – which makes it weird that OAuth came before OIDC? And what about the distinction between authorization and delegation – is authorization exclusively about the P*P architecture and not about what an OAuth “authorization server” does?

OAuth and OIDC. Author’s collection.

Before OIDC existed, things were no less confusing. During my analyst days a decade-plus ago, I frequently fielded inquiries where clients asked, “SAML or OAuth?” While the question was in some sense like asking “Lettuce or stainless steel?”, in another sense I totally got it.

So in 2011 I wrote a research report on “protecting enterprise APIs with a light touch,” which I believe was the first Forrester report focusing on OAuth. Along with describing the classic OAuth use cases of user-delegated authorization for access to APIs and tracking and protecting calls to services on the client app’s own behalf, I also reviewed the emerging use case of cross-domain federated single sign-on for website users, which leveraged its double-redirect pattern in a way that looked awfully similar to SAML.

The only thing OAuth was missing was a standardized way to carry actual identity information – a problem ultimately solved by OIDC. So this is how we can understand OIDC as an extension of OAuth, coming after its invention, and yet as a precursor to what has to happen in the decision-making process of authorization.

I thought it might be useful to share the diagrams I’ve used for a long time for explaining OAuth in relation to other protocols.

OAuth and OIDC

Keep your eye on the items that have a green glow. Those are the overlay of OIDC on OAuth.

OAuth uses an authorization server to protect whatever endpoints a resource server makes available. OIDC leverages this pattern for modern SSO by defining a standardized identity service with an endpoint, UserInfo, that serves ID tokens. It actually a bit does more than that, allowing addition of an ID token to the AS response from the token endpoint. This makes it an extension vs. a profile.

OAuth and UMA

User-Managed Access (UMA) messes with OAuth somewhat more than OIDC does, putting it firmly in extension territory – I sometimes refer to it as an “application” of OAuth. This time, the items with a green glow are the special bits of UMA above and beyond OAuth.

The first part of UMA’s extension of OAuth is the addition of someone who is not the resource owner – and they’re the one using the client trying to access something.

Note the dotted line around OAuth’s AS and RS. They are presumed colocated – or, put another way, there is no standardized method of trust establishment between them. The second part of UMA’s extension of OAuth is formally establishing this trust to open up an n:n ecosystem of AS’s and RS’s, which it calls federated authorization.

The third part of UMA’s extension of OAuth is to give the resource owner control of these AS/RS introductions. What does it use to achieve this? Why, OAuth, of course! (Snake-eating-its-own-tail time.) This allows for different API ecosystems – FHIR, Open Banking, and connected car in the picture – to be protected in a unified way.

Clear as mud? I hope this serves as a small contribution to the “how to understand the OAuth stack” topic that keeps coming up, many years after OAuth2’s ratification.

If you have comments, questions, explanations, or even reminiscences from the old days, I hope you’ll add them in the comments.