Nowadays, most websites and applications allow you to authenticate yourself through your Google, Microsoft, Apple, or Facebook account. Thus, there is no need to come up with a new username and password each time because you will be able to authorise yourself through an already trusted account in just a few clicks. The technology that makes this possible is OpenID Connect (OIDC).
In this OpenID Connect Explained guide, we will try to figure out what it is, why it was invented, how it differs from OAuth 2.0, and what made it so popular. The main purpose of this article is to explain everything in layman’s terms without unnecessary technical terms.
OpenID Connect Explained
However, when talking about OpenID Connect, one should realise that OpenID Connect (OIDC) is an authentication protocol that is based on OAuth 2.0.
While OAuth 2.0 is all about authorisation. The question it is trying to answer is:
What is this application authorised to do?
OpenID Connect extends it further and tries to answer a very relevant question:
Who is the user?
Put simply, OAuth 2.0 allows the app to do something with some resources, and OIDC is trying to identify who the user behind this app is.
It is like the following:
OAuth 2.0 is like giving the ticket to someone, which allows him to attend the concert.
It is like checking the passport of this person to make sure he is really who he is.
Why Was OpenID Connect Created?
Before the use of OpenID Connect, there was usually the need for developers to build custom login solutions.
All websites kept their username and password combinations separately, and therefore, made security a challenge.
It resolved this issue by having applications trust an external identity provider.
Rather than having every application keep passwords, users log in via trusted identity providers such as Google or Microsoft, which then confirm that the user is who he/she claims to be and send the relevant information back to the application.
OpenID Connect Explained: The Main Components
To understand the concept you should know the key participants involved during the authentication process.
End User
The end user is simply the person trying to log in to an application.
Relying Party (Client)
This is the website or app that wants to verify the user’s identity.
For example:
- Shopping websites
- Banking apps
- Social media platforms
- Business software
OpenID Provider (Identity Provider)
The OpenID Provider authenticates the user and issues secure tokens.
Popular providers include:
- Microsoft
- Okta
- Auth0
- Keycloak
These providers are responsible for verifying your identity before allowing access.
How OpenID Connect Works
One of the easiest ways to understand OpenID Connect is by following a typical login process.
Step 1: User Clicks Sign In
The user opens an application and selects “Sign in with Google” or another supported provider.
Step 2: Redirect to Identity Provider
The application redirects the user to the trusted identity provider along with a request asking for authentication.
Step 3: User Logs In
The provider displays a secure login page where the user enters their credentials or uses an existing session.
Step 4: Authentication
The provider verifies the user’s identity.
If additional profile information is requested, the user may also be asked for consent.
Step 5: Authorization Code Is Returned
Once authentication succeeds, the provider sends an authorization code back to the application.
Step 6: Tokens Are Issued
The application’s backend exchanges this code for secure tokens, including:
- ID Token
- Access Token
Step 7: Identity Is Verified
The application validates the ID Token and creates a login session for the user.
If needed, it can also request extra profile information using the Access Token.
This entire process usually takes only a few seconds.
Understanding ID Token and Access Token
A key part of OpenID Connect is understanding the difference between these two tokens.
ID Token
The ID Token proves the user’s identity.
It is usually a signed JSON Web Token (JWT) containing verified information such as:
- User ID
- Name
- Email address
- Authentication time
- Token expiration time
- Identity provider information
Because it is digitally signed, the application can verify that the information has not been changed.
Access Token
The Access Token serves a different purpose.
Instead of identifying the user, it allows the application to access protected APIs and resources based on the permissions granted by the user.
In short:
- ID Token = Who the user is
- Access Token = What the application can access
Scopes and Claims in OpenID Connect
Another important part of OpenID Connect Explained is understanding scopes and claims.
Scopes
Scopes tell the identity provider what information the application wants.
The most important scope is:
- openid
Without this scope, it does not work.
Other common scopes include:
- profile
- address
- phone
Applications should request only the information they actually need.
Claims
Claims are pieces of information about the user.
Examples include:
- Name
- Email address
- Profile picture
- Unique user ID
- Authentication time
These statements are included either within the ID Token itself or via the UserInfo endpoint.
OpenID Connect vs OAuth 2.0
A lot of people get confused about these two.
- OAuth 2.0 is all about authorization.
- The idea is to enable applications to access the API or resources on behalf of the user.
- But OAuth 2.0 doesn’t prove who the user actually is.
- OpenID Connect provides this feature by adding an identity layer to OAuth 2.0.
- This is why OpenID Connect is described as:
- OpenID Connect = OAuth 2.0 + Identity
OpenID Connect vs SAML
Another one in OpenID Connect discussions is that of comparing it to SAML.
SAML is an older authentication protocol, widely adopted in enterprise systems.
It makes great use of XML technology and was designed for browser applications only.
Unlike that, OpenID Connect leverages such modern technologies as JSON, REST APIs and JWTs.
And this is why it is more suitable for:
- Mobile apps
- Cloud-based applications
- Web applications
- APIs
- Microservices
SAML is used by some companies for their legacy systems while others prefer OpenID Connect for newer ones.
Discovery and Automatic Configuration
It includes a useful discovery feature that makes integration easier.
Identity providers publish a standard configuration document containing details such as:
- Authorization endpoint
- Token endpoint
- UserInfo endpoint
- Public signing keys
- Supported scopes
- Supported authentication methods
Applications can automatically retrieve this information instead of requiring developers to configure everything manually.
This simplifies integration with multiple identity providers.
Security Benefits of OpenID Connect
Security is one of the biggest reasons why it has become so popular.
Instead of every application storing passwords, authentication is handled by trusted identity providers with advanced security systems.
Additional security features include:
- Digital signatures for tokens
- Multi-factor authentication (MFA)
- Device verification
- Secure session management
- Public-key cryptography
- User consent for sharing profile information
Applications also collect less personal information because they request only the scopes they actually require.
This helps improve user privacy.
Where Is OpenID Connect Used?
You probably use OpenID Connect every day without realizing it.
Some common examples include:
- Signing in with Google
- Signing in with Microsoft
- Social login on websites
- Enterprise Single Sign-On (SSO)
- Mobile application authentication
- Cloud software platforms
- API-based services
- Modern microservices environments
Any time one secure login works across multiple applications, OpenID Connect is often working behind the scenes.
Conclusion
This OpenID Connect Explained article highlights the importance of OpenID Connect being one of the most critical authentication protocols on the internet. As an extension to OAuth 2.0, It makes sure that websites have a standardised and secure method of authenticating users and also provides authorization support.
Rather than individual sites handling credentials, the process of authentication is handled by trusted identity providers,, which provide secure tokens that can be verified by applications.
Whether you use social sign-ins or single sign-on to access enterprise applications or sign into any mobile application, it is likely that it is improving the experience of securing your credentials and identity over the web.
