OAuth and OpenID Connect
If you’re a software developer on the web today, chances are you’ve heard of OAuth. There is a lot of misconception about what OAuth is. Some people think OAuth is a login flow (like when you sign into an application with Google Login), and some people think of OAuth as something related to security.
What is OAuth 2.0?
OAuth 2.0 is an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications. It’s used from large-scale providers like Facebook and Google to small companies and startups.
- A client application can request an access token to gain access to an API.
- OAuth 2.0 defines how a client application can securily achieve authorization.
- The standard defines how to use these endpoints for different types of client applications.
- IdentityServer, Azure AD and other frameworks implement the OAuth2 standard.
What is OpenID Connect?
OpenID Connect is a simple identity layer on top of the OAuth2 protocol.
- A client application can request an identity token (next to an access token).
- That identity token is used to sign in to the client application.
- Defines an additional endpoint that allows a client application to get additional information on the user.
- OpenID Connect is the superior protocol: it extends and supersedes OAuth2.
- Even if the client application only requires authorization to access an API, we should use OIDC instead of plain OAuth2.
OpenID Connect and OAuth 2.0 are very similar — in fact OpenID Connect is an extension on top of OAuth 2.0. The two fundamental security concerns, authentication and API access, are combined into a single protocol — often with a single round trip to the security token service.
Protocol Flows
While this can be incredibly frustrating, it’s no accident that OAuth is actually made up of many different RFCs, building upon each other and adding features in different ways.
OAuth has been patched and extended a lot in the last decade of experience deploying systems using it. It’s been extended in ways the original authors could never even see coming. Keep in mind that when OAuth 2.0 was published in 2012.
A flow is a description of how an application is talking with the Security Token Service (STS). The most important flow is authorization code flow with PKCE. They are working in OAuth 2.1 which is a simplification, taking the lessons learned in the last years. The implicit and password flows will be deprecated.
The OAuth core spec (RFC 6749)
Define four grant types:
- Authorization Code
- Implicit
- Password
- Client Credentials
It used to be the case that the Implicit grant was recommended for both JavaScript apps as well as native apps.
PKCE (RFC 7636) and “OAuth 2.0 for Native Apps” (RFC 8252)
It became apparent that a better solution was needed for mobile apps, so PKCE (RFC 7636) was created to provide a way to use the Authorization Code flow without a client secret.
Device Grant (RFC 8628)
A new class of device arose along with a need to use OAuth with them: devices that have no browser or lack a keyboard, such as an Apple TV or YouTube streaming video encoder.
Current State
It all started with a core OAuth RFC, than things were added and removed, and turned it into an entirely different set of recommendations.
So what started out as a list of four grant types, now looks more like this.
The problem is that it requires reading far too many RFCs to understand this landscape. That’s why there are people currently working on OAuth 3.0 which will take literal years to finish.
