Understanding OpenID Connect (OIDC)

Creating user accounts for multiple websites and apps can be a humdrum process. Users often have to remember their usernames and passwords for each and every service they use online and this can greatly impact their user experience. OpenID Connect solves this problem by allowing users to create an account with Identity Providers, and then access various online services by authenticating themselves with the Identity providers. This process, called Single Sign-On (SSO), lets you access multiple online services through a single account.

If you are reading this, then chances are more likely that you would have used Single Sign-On at least once in your life. Perhaps, you could be using your Facebook or Google account to sign into other services such as Quora or Vimeo. So, how does this work? How can authenticating yourself with just one Identity Provider (IdP) allow you to access multiple services online?

Before answering this question, keep in mind that OpenID Connect is just one way of implementing Single Sign-On. There are other ways of implementing it too with SAML being another prominent one. OpenID Connect is becoming more popular owing to its simplicity and it being based on OAuth 2.0.

Authentication vs. Authorization

Prior to understanding OpenID Connect, it is imperative that you understand how OAuth 2.0 works since OpenID Connect uses OAuth 2.0 to authenticate users. Head over here if you want to learn about OAuth 2.0.

OAuth 2.0 is a protocol that is used to authorize users whereas OpenID Connect is used to authenticate users. As is so often the case, many tend to conflate both authorization and authentication. Authentication is a process by which you prove your identity—you prove you are who you claim to be. Authorization, on the other hand, is a process by which you prove that you have the authority to do something.

For example, offices implementing access control systems often give visitors an access card or a visitor’s pass to allow them to enter their office. Say, you want to visit the HR department of a company. First, you will be asked to provide your identity card at the reception to confirm your identity. This process is called authentication. Next, the officer-in-charge would go through their protocols and regulations to see if you can be granted access, and if you can be, then you will be given an access card which will allow you to enter the HR department only. This is called authorization.

OAuth 2.0 isn’t an Authentication protocol

Since authorization using OAuth 2.0 involves implicit authentication (before you can decide whether or not to permit a client accessing your resources, it should be affirmed you are who you actually claim to be), many erroneously assume OAuth 2.0 to be both an authorization and authentication protocol. Even though once a user authorizes a client to access his protected resources, a client can verify a user’s identity by requesting the identity information of the user using the issued access token, this isn’t a part of the OAuth 2.0 protocol and hence, different service providers can implement this in different ways.

In OAuth 2.0, the client is only granted an access token which gives information only about whether or not a client is allowed access to a protected resource. The service provider shall never know anything about the identity of the client purely through the OAuth 2.0 protocol.

OpenID Connect builds upon OAuth 2.0

This is a missed opportunity because users have to authenticate themselves with the authorization server before they are granted an access token. If that authenticated identity information can be relayed to the client using a certain standard, then that would allow authentication as well. This is exactly what OpenID Connect accomplishes by sending an ID token providing information about the user to the client in addition to the access token during an OAuth 2.0 flow.

Therefore, OpenID Connect builds upon OAuth 2.0 to allow Identity Providers to authenticate users and share the authentication information with other service providers. Let’s see how this happens.

How does OpenID Connect work?

Let’s assume you are trying to sign into Quora using your Google account. Your client can use any of the OAuth 2.0 grant types. When sending a request to the authorization server (called the identity provider in the context of authentication) with the redirect URL, client ID, and response type, the scope here would be set to “openid” to tell the Identity Provider that you want the authentication information. The required claims such as the username, email address, gender can also be sent in a “claims” parameter.

Once redirected to the identity provider, you will be logging into your Google account and would be consenting to Google sharing your information with the client. Then, you will go ahead with the rest of the flow depending on the grant type, and when you obtain the access token, you will also get an ID token.

This ID token is a JSON Web Token (JWT) that carries the standard OpenID Connect claims such as name, nickname, email, etc. The full list of such standard claims can be obtained here.

Thus, a client can know who the user is by relying on a trusted identity provider to authenticate users. This provides users the convenience of using only one account to log into several online services.

Moreover, clients can use the access token issued to query the UserInfo endpoint of Identity Providers to get more information about the users.

Thus, it can be seen that OpenID Connect is a very simple protocol built on top of the widely used OAuth 2.0 protocol to facilitate identity provision and Single Sign-On.