What is OpenID Connect?
A contemporary authentication system called OpenID Connect (OIDC) is frequently used to confirm user identification and provide secure Single Sign-On (SSO) for cloud services, mobile apps, and websites. The OAuth 2.0 authorization framework serves as the foundation for OIDC, an authentication layer. OIDC provides authentication to OAuth 2.0, which specifies authorization (which shows what resources a user can access) and verifies that the user is who they say they are.
OIDC uses standard JSON-based data formats, namely JSON Web Tokens (JWTs), and is lightweight to achieve simplicity and use. Compared to previous standards like OpenID 2.0 (which required XML), this method is far simpler for developers to implement.
Key Components of OpenID Connect
To enable the safe transfer of identity information, OIDC consists of the following essential elements:
End User / User: The person attempting to access a service or log in.
Relying Party (RP) / Client: The program or service (such as a news website or smartphone app) that asks for personal information from users and contracts out its authentication process.
OpenID Provider (OP) / Identity Provider (IdP): The server that manages user authentication and token distribution. Auth0, Microsoft, Google, and Okta are typical instances.
ID Token: A JWT that includes user identity information, including email, name, and user ID. The result of the authentication procedure is the ID Token, which the RP uses to verify the user’s identity.
Access Token: To grant access to protected resources or APIs, an OAuth 2.0 token is required.
UserInfo Endpoint: An optional endpoint supplied by the OP that provides further end-user profile information (claims).
You can also read What is Diameter protocol Explained, Applications & Commands
How Does OIDC Works?
Known as the Authorization Code Flow, a standard OIDC authentication procedure consists of the following general steps:
Initiation: An application (the Relying Party, or RP) is attempted to be accessed by the user.
Redirection: The user is taken to the OpenID Provider (OP) by the program.
Authentication and Consent: The user uses biometrics, MFA, or a password to authenticate with the OP. The user may also be asked for permission by the OP to give the application particular personal data.
Token Issuance: The OP returns an ID Token (JWT) and an Access Token to the application after successful authentication and consent.
Validation and Login: The application uses the identification information contained in the ID Token which is signed by the OP to verify its integrity and log the user in.
Optional Retrieval: The application may choose to retrieve more user information from the OP’s UserInfo Endpoint using the Access Token.
OIDC greatly improves security by using tokens instead of needing the application (RP) to manage or keep the user’s credentials.
You can also read What is Kerberos, Limitations of Kerberos and Components
OIDC Flows
Different “flows” are used by OIDC to manage token supply and requests, accommodating different kinds of applications. The OAuth 2.0 Implicit Flow is deprecated because to security concerns, and grants have been abandoned in favour of safer alternatives.
The most popular and safe flows consist of:
Simplified Authentication Flow (Authorization Code Flow)
Grant types for OAuth 2.0 Authorization Codes are used in the most popular and safe OIDC flow:
- Request: The Relying Party (RP) application’s “Sign in with Google” button is clicked by users. Using a client_id and the unique openid scope, the RP reroutes the user’s browser to the authorization endpoint of the OpenID Provider (OP).
- Authentication: The user is authenticated by the OP using MFA and credential prompts.
- Code Return (Front-Channel): The OP provides a temporary, one-time Authorization Code and reroutes the user back to the RP’s registered redirect URI following a successful login.
- Token Exchange (Back-Channel): After receiving the code, the server-side component of the RP safely trades it for the actual tokens using the OP’s Token Endpoint:
- ID Token: Utilized by the RP to create a local session and confirm the user’s identity.
- Access Token (Optional): Used to make calls on the user’s behalf to other APIs or the OP’s Userinfo Endpoint.
- Access Granted: The user is given access to the application once the RP extracts the user’s identity claims and verifies the ID Token’s signature and expiration.
Authorization Code Flow with PKCE:
Single-page applications (SPAs) and native mobile apps are examples of public clients that commonly use this extension (Proof Key for Code Exchange). An additional defence against authorization code injection attacks is provided by PKCE.
Implicit Flow:
For applications that use browsers and handle non-sensitive data, the tokens are sent straight to the browser. Because tokens are exposed to the browser, this route is generally deprecated and discouraged for sensitive data.
You can also read What is Open System Authentication OSA and How it Works?
What’s in the ID Token (JWT)?
Identity claims such as these are commonly included in the structured, signed, and (optionally) encrypted string known as the ID token.
sub(Subject): The user’s unique identification.iss(Issuer): The OpenID Provider’s URL, which issued the token.aud(Audience): The Relying Party’s Client ID for which the token is meant.exp(Expiration Time): When the token expires, it loses its validity.auth_time: After the user had been verified.
Where OIDC Is Used
- Google Sign-In
- Microsoft Identity Platform
- Amazon Cognito
- Okta, Auth0, Ping Identity
- Enterprise SSO platforms
- Cloud-native applications
Importance and Benefits of OIDC
OIDC has emerged as the industry standard for SSO and identity providing because of a number of benefits:
Enables Seamless SSO: Users can access numerous websites and apps using a single set of login credentials (such as Google or Facebook), reducing the amount of time they must spend signing in.
Enhanced Security: By preventing the sharing of user credentials with applications and centralizing authentication, it drastically lowers the risk of credential theft and password-related breaches. Additionally, Multi-Factor Authentication (MFA) and other robust security mechanisms are supported.
Modern and Scalable: Because it makes use of lightweight, JSON-based JWTs, it may be used with contemporary applications such as APIs, SPAs, and mobile apps.
Interoperability: Major identity providers like Google and Microsoft embrace this open, standardized protocol, which guarantees uniformity across many services.
Identity and internet access are two issues that OIDC resolves. It functions similarly to a global passport system: the OpenID Provider (OP), a reliable government agency, authenticates you and provides your JWT ID Token, or passport, to the Relying Party (RP) application. After accepting the passport, the RP application determines which particular restricted areas or APIs you are permitted to access by obtaining an Access Token (similar to a visa) upon request.
You can also read Benefits of SAML Security Assertion Markup Language