OpenID Connect (OIDC) is an open standard and interoperable authentication protocol built on top of the OAuth 2.0 authorization framework. It is an identity layer designed to provide a standardized and secure way for applications to handle authentication and obtain information about users.
OIDC enhances OAuth 2.0 by introducing identity layer features, making it suitable for Single Sign-On (SSO) and user identity scenarios.
To understand how OIDC works, you first need to understand how OAuth 2.0 works. You can find out more information about OAuth 2.0 in my previous article.
Why OIDC?
OAuth 2.0 was built as an authorization protocol, to delegate resources protected access to third-party applications. However, it was not designed to address user authentication.
OpenID Connect was developed to address this authentication issue, by extending the OAuth 2.0 protocol.
OIDC implementation is “simple” enough to be integrated with basic applications, while having robust security options to fulfil enterprise level requirements.
OIDC enables Single Sign-On functionality, allowing users to log in once to an identity provider (IdP) and then access multiple applications without needing to log in again. This improves user experience and reduces the need for users to remember multiple sets of credentials.
It supports the concept of federated identity, where an application can rely on an external IdP (like Google, Microsoft, or other identity providers) to handle authentication. This reduces the burden of managing user credentials and security concerns for the application.
How OIDC works
The OIDC flow looks very similar to the OAuth flow. The differences being that, in the initial request, a specific scope of openid is used and, alongside of the Access token received by the Authorization server, an ID token is also sent.
Roles
The roles defined in OIDC are named differently from OAuth.
- End-User: It is the user (or system) for which the identity is requested by the Relying Party.
- Relying Party (RP): It is the client application that wants to verify the identity of the end-user and obtains user information from the identity provider.
- OpenID Provider (OP): The OP (or Identity Provider) is an entity that has implemented the OpenID Connect and OAuth 2.0 protocols. It is in charge of authenticating the user.
Scopes and Claims
Scopes define the level of permission and reasons for which access to resources may be granted to the Relying Party.
Scope is a “group” that contains multiple Claims, and Claims are simply a name / value pair object.
Scopes are predefined in OIDC (you can create your custom scopes), but the openid scope is required.
Tokens
- Access Token: As in OAuth, the access token is exchanged by the Relying Party to access the protected resource. The Access Token value can’t be understood by the Client, only the Resource Server will know if it is valid.
- ID Token: The ID token is a JSON Web Token (JWT) issued by the identity provider to the client application after successful authentication. It contains information about the end-user's identity and other Claims. The Client is able to read the information / Claims contained in the ID token.
Abstract Protocol Flow
The example below describes the flow of actions on how the OIDC protocol works. It’s a super company that has a Microsoft Azure cloud platform subscription, and every employee has a specific account in an Active Directory.
The company has developed a Single Page Application client portal, to which the employees can connect to consult their remaining holiday balance and their payslips.
-
The application (Relying Party) requests authorization from the employee (end user) and receives an authorization Grant
-
The authorization grant is used to obtain an access token and ID token from the OpenID Provider. The Relying Party can retrieve the employee identity information (email, username, name, etc.) from the ID Token.
-
The access token is used to retrieve the protected resources (holiday balance, payslips) from the Resource server.