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?

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

  • 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

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)

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

Device Grant (RFC 8628)

Current State

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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store