OpenID Connect is a standard designed and developed by the OpenID foundation. It may be found on top of the OAuth 2.0 specification (https://tools.ietf.org/html/rfc6749). OAuth 2.0 is an authorization framework for access delegation. We can also call OpenID Connect an identity layer built on top of OAuth 2.0.
There are two main parties, the OpenID provider and the client application are involved in addition to the end-user in a typical OpenID Connect login flow.
The OpenID provider manages;
- user attributes and credentials,
- and lets the users log in to client applications following the OpenID Connect protocol.
- These client applications and OpenID providers can belong to the same organization or different organizations.
- We call that client application a third-party client application when a client application comes from an outside organization from where the OpenID provider belongs to.
- If eBay is the client application and Apple is the OpenID provider when we log in to eBay with our Apple ID. They belong to two different organizations. We can call eBay a third-party client application.
The client applications rely on;
- An OpenID provider to authenticate users.
- We’ll use popular open-source OpenID providers in our samples.
- How we set up those tools could vary from time to time with new releases.
- We’ll keep the setting up steps of those OpenID providers from our GitHub repository (https://github.com/openidconnect-in-action/samples).
OpenID Connect is a standard that defines how a client application communicates with an OpenID provider to identify a user. How exactly the communication between a client application and the OpenID provider takes place is defined in the OpenID Connect Core specification (https://openid.net/specs/openid-connect-core-1_0.html) developed by the OpenID foundation. There are a few more specifications developed by the OpenID Foundation to address some other use cases around OpenID Connect. We’ll introduce those specifications as we delve deep into OpenID Connect.
OpenID Connect vs OAuth 2.0
The OAuth 2.0 Framework provides the detail of overarching patterns for granting authorization. But it does not define how to actually perform authentication. The application using OAuth builds a specific request for permissions to a third-party system. It does handle the authentication process and returns an Access Token representing success. The IdP may require additional factors for example SMS or email but that is entirely outside the scope of OAuth. At the last, the contents and structure of that Access Token are undefined by default. This ambiguity guarantees that Identity Providers will build incompatible systems.
Fortunately, OpenID Connect or OIDC brings some sanity to the madness. This is an OAuth extension. It does add and strictly defines an ID Token for returning user information. It may return specific fields that our applications can expect and handle when we log in with our Identity Provider. The OIDC is just a special and simplified case of OAuth, not a replacement. It uses the same terminology and concepts.
We always need to think carefully about claims. A claim is simply the name or value pair embedded within our Access and ID Tokens. For example, we might have a user_id or email claim so downstream applications can use them to create profiles or make decisions. The OAuth main specification doesn’t introduce the concept of claims or even include the word claim. This is helpful because we can define it whenever we need it.
The use of OpenID Connect safeguards us quite a bit. It explains a simple set of claims for user details such as name, address, and similar. The user knows what information they are sharing and applications know how to use it if we only use those and limit access according to the proper scopes.
We add extra claims alternatively as the routine desire is to have a user-unique identifier. We use an obfuscated primary key that has no meaning outside our system if we’re thinking about it. That could be a customer identifier if we’re not careful, an employee number, or even a Social Security Number.