A few weeks back, we discussed OAuth, a protocol that we use for delegated authorization. This is basically a process where a user can authorize one service to access the user’s data from another service. One important thing that OAuth doesn‘t do is authentication—it doesn’t verify whether a user is who they claim to be.
This is where OpenID Connect (OIDC) steps in. It’s a protocol for authentication that runs on top of OAuth 2.0. OIDC is the third version of the OpenID protocol. It was designed to overcome some of the limitations of the early versions and to be a little more developer friendly. The OIDC protocol provides a relatively simple way for developers to authenticate users across apps and websites, all without the developer having to store or manage the user passwords.
An example of OpenID Connect
Let’s use an example of a new social media app to give you an idea of what OpenID Connect actually does. The developers of this app may not want to deal with all of the hassle of securely managing user passwords themselves. Instead, they might decide to turn to an OpenID provider like Google to do it for them.
To give you a slightly simplified explanation of how it all works, when a user wishes to log in to the social media app, the client can send them straight to Google’s login domain. Once the user is at Google’s login domain, they can sign in to Google using their Google account details. The Google login domain then hands the user an authorization code and directs them back to the client.
At this stage, the client then sends the authorization code back to the Google login domain, which then verifies whether the code is valid. If it is, the Google login domain will send the client an access token. The client then validates the access token.
The whole process may seem a little convoluted, but once the client has validated the access token, the social media app can then grant the user access to their account. The interesting thing about the whole process is that the social media app never authenticates the user—Google does it instead. Since the social media app trusts Google’s authentication process, it grants the user access to its resources. This means that the developers behind the app can securely grant access to users, without the substantial responsibility of having to secure and manage user passwords.
Important OpenID Connect terms
To complicate things, OIDC uses slightly different terminology to OAuth:
- End user – The user that needs to be authenticated to access resources from the relying party.
- The relying party – This is an OAuth 2.0 client application that needs the end user to be authenticated. In our example, this is the social media app.
- The OpenID provider – The OpenID provider is an OAuth 2.0 authorization server that can authenticate the end user for the relying party. In our example, this is the Google login domain.
To put it all together using the right terminology, the user (the end user), wants to log in to the social media app (the relying party). They are redirected to the Google login domain (the OpenID provider), which authenticates the user and sends them back to the social media app (the relying party) with a code. The social media app then sends the Google login domain (the OpenID provider) the code. The Google login domain (the OpenID provider) validates the code and then sends back an access token, which then allows the user to access their account on the social media app (the relying party). The user never logs in with the social media app (the relying party) directly.
