Clever Engineering Blog — Always a Student

OpenID Connect

By Keith Richards on

Adding AuthN to OAuth2.0

OpenID Connect (OIDC) is an authentication protocol that sits on top of the OAuth2.0 protocol. It provides a standardized way for clients to authenticate users and obtain information about their identity. In simple terms, OpenID Connect allows users to log in to different applications using a single set of credentials. It does this by leveraging the existing OAuth2.0 framework for authorization, adding a layer of identity information on top. OpenID Connect also provides additional features, such as support for user consent, user defined scopes, and standard claims for user attributes. This makes it a flexible and extensible protocol that can be adapted for many different use cases.

The OAuth2.0 protocol focuses solely on authorization. When a user begins the OAuth flow, it is assumed that the user has already signed in and their identity has already been verified. OAuth’s core responsibility is to allow or deny a user access to protected resources. OpenID Connect builds upon the OAuth protocol and extends it to include authentication too. So instead of assuming a user is logged in, OIDC will actually perform the login then allow or deny access to resources.

Background

OpenID Connect has its roots in the OpenID 2.0 protocol, which was first introduced in 2006 as a way to provide a decentralized single sign-on solution for the web. OpenID 2.0 suffered from several limitations and complexities, however, and was not widely adopted. In response, a group of industry experts formed the OpenID Foundation in 2007 to develop a new version of the protocol that would address these issues and provide a modern solution for identity and authentication. This effort eventually led to the development of OpenID Connect, which became an official standard in 2014. Since its release, OpenID Connect has gained widespread adoption and support from many major players in the tech industry, including Google, Microsoft, Amazon, and others.

Who’s Who

There are two principal actors in the OIDC flow. They are the “relying party” and the “OpenID provider”.

The first actor is the “relying party”. This actor is similar to the “Client” in OAuth2. The relying party is a website or application that wants access to some protected information. It makes requests on behalf of a user.

The other primary actor is the “OpenID provider”. The OpenID provider is responsible for authenticating and authorizing a user. Conceptually, this is similar to the “Authorization Server” in OAuth. Once authorized, the OpenID provider gives the relying party an access token for subsequent requests, as well as an ID token containing information about the user, such as their name and email address, as well as metadata about the authentication event.

Putting the Pieces Together

The relying party initiates an authentication request by redirecting the user’s browser to the OpenID provider with a special authorization request containing information about the client and the desired scopes. The user is prompted to authenticate with the OpenID provider, which may involve entering a username and password or using a different authentication method such as single sign-on. Once the user is authenticated, the OpenID provider generates access and identity tokens for the user. The relying party can then use the access token for subsequent requests. The relying party can also obtain the user’s identity information from the ID token. Optionally, the OpenID provider may host an additional Userinfo Endpoint that provides additional user information beyond what is included in the ID Token.

Much like OAuth, OIDC supports scopes to request specific access to user information or features during the authentication flow. Scopes indicate the specific information or features that the client application needs access to, such as the user’s name, email address, or profile picture. The user’s information is commonly referred to as “claims”. By specifying a scope or scopes, the relying party asks the OpenID provider to include specific details about the user.

Some common scopes include:

  • openid: Indicates that the authentication request is an OpenID Connect request and should return an ID token. This scope is required in the OIDC flow.
  • profile: Requests access to the user’s profile claim, which includes information such as their name, profile picture, and preferred language.
  • email: Requests access to the user’s email and email_verified claims.
  • address: Requests access to the user’s address claim.
  • phone: Requests access to the user’s phone_number and phone_number_verified claim.

A Real World Scenario

In our last article, we talked about an educators conference that had a number of seminars aimed at specific groups within school districts. There were administrative seminars geared towards principals and administrative staff. STEM sessions were available to teachers and educational staff in science and math fields. Sessions were limited to members of the target audience. Only administrators were allowed to participate in the administrator sessions, and only STEM teachers in the STEM sessions. Conference attendees wore a color-coded lanyard with a name tag that designated their group.

When attendees arrived at the conference, they were asked to sign in at kiosks lining the entry hall. As people sign in, the kiosk scans the event registry for their name. If the kiosk finds a match then it knows the individual is allowed to attend the conference. It also knows some basic information about the user such as sessions the individual can attend as well as some personal information to include on their badge, such as the individual’s full name, preferred pronouns and their headshot. Finally the kiosk prints their badge and dispenses the appropriate lanyard.

In this scenario, the kiosk acts as the relying party and the event registry is the OpenID provider. The kiosk first checked in with the registry to authenticate the user. The registry responded by verifying the user’s identity (generating an ID token) and checked their role (granting an access token). The kiosk’s lookup also included the profile scope so it could add some additional user details to the badge (claims).

OpenID Connect is an extension of the OAuth2.0 protocol that gives third-party applications a way to authenticate users and retrieve some personal information about them. A number of Clever’s application partners leverage OIDC to verify our users’ identities and validate their app access. Our school districts define the scopes and claims available to applications to ensure only the appropriate information is shared with third parties. In the next edition of this series, Clever’s Auth team will discuss an alternate approach to authentication through the SAML protocol.