In more technical terms, OIDC is an authentication layer that is built on top of OAuth 2.0, an authorization framework. OIDC cannot be considered a separate protocol. Out of necessity, it was created later as an extension of OAuth 2.0 to overcome OAuth's drawback of having only the authorization functionality and not the authentication functionality. OAuth provides resource access to third-party applications, also known as relying parties or clients. OpenID Connect grants user authentication or login to those third-party applications.
OpenID Connect was published in February 2014, succeeding the previous IdP standards like SAML, OpenID 1.0, and 2.0, and superseding these standards in terms of usability and simplicity. Since OIDC is a part of OAuth 2.0, we need to know what OAuth 2.0 is and does, to understand OIDC better.
- What is OAuth 2.0 and how is it different from OpenID Connect?
- Important terminologies in OpenID Connect and OAuth 2.0
- How does OpenID Connect work?
- What are the different types of OpenID Connect flows?
- Benefits of OpenID Connect
- What is SAML and how is it different from OpenID Connect?
- Enabling OpenID Connect SSO using ADSelfService Plus
What is OAuth 2.0 and how is it different from OpenID Connect?
OAuth stands for "Open Authorization" and is an authorization framework that allows a website or an application to access resources which are hosted by other web applications on behalf of the user. OAuth 2.0 restricts the client application's resource access to only whatever specific resource is needed. It also takes the user's consent for the client application to access resources and does not share the user's credentials over the network.
The OAuth 2.0 protocol is the base on which the OpenID Connect protocol is built. The main difference between OAuth 2.0 and OpenID Connect is their respective authorization and authentication functions. Clients use OAuth 2.0 to request access to a particular resource on behalf of a user, whereas OIDC is used by clients to request access to a user's basic profile details to verify the user's identity. OAuth 2.0 clients only request access to an application's API on behalf of a user and do not access specific user information. Therefore, OpenID Connect is called an authentication protocol, and OAuth 2.0 is called an authorization framework.
OAuth 2.0 uses access and refresh tokens to grant resource access to the clients. OIDC additionally uses the identity token (ID token) to convey the identity of the user using the application.
Important terminologies in OpenID Connect and OAuth 2.0
OpenID provider
An OpenID provider, OIDC provider, or IdP, is the entity contacted by the requesting party to verify a user's identity. The IdP uses the OIDC protocol to perform user authentication and issue ID tokens.
Relying party
A relying party or client in OIDC is any third-party website or application that requests the IdP for verification of the user's identity. In OAuth 2.0, a client is any third-party website or application that requests the authorization server for resource access.
ID token
In OIDC, an ID token having the user authentication process's outcome is returned to the relying party by the IdP. It is in the JSON Web Token (JWT) format and is comprised of a header, payload, and a signature. The payload portion contains claims, which are the requested user identity data entries returned by the IdP, such as name, email ID, and so on.
Refresh token
A refresh token is used in OAuth 2.0 to acquire a new access token once it expires, without any interaction with the resource owner. This ensures that the resource owner does not have to authenticate more than once in the process.
Authorization server
In OAuth 2.0, the server or application from which a resource is requested is called an authorization server. The authorization server grants the requesting party access to its resource. The terms IdP and authorization server are used interchangeably in OIDC and OAuth 2.0.
Resource owner
A resource owner or user is the person using the client. The resource owner technically owns the resource that the relying party is trying to access. The resource can only be accessed by the client if the resource owner gives their consent to do so. This term has significance only in OAuth 2.0 and not in OIDC.
Access token
In OAuth 2.0, the authorization server grants resource access to a client by providing the client with an access token. An access token acts like a resource unlocking key because it has authorization details like what resources the client has access to and how much access it has (scope). It does not have details about the user's identity and cannot be used for user authentication. The OIDC protocol also uses access tokens.
How does OpenID Connect work?
Since OIDC is built as an authentication layer on top of the OAuth 2.0, it works quite similar to OAuth's authorization code flow with slight deviations towards the end of the code flow process. The complete OIDC authorization code flow has been outlined below.
When a user wants to access a client application, the client initially takes the user to the IdP's login page. The client also passes the redirect uniform resource identifier (URI), response type, and scope parameters as a request to the IdP alongside. The redirect URI parameter tells the IdP which page the user must be redirected to once the authentication is successful. The response type parameter specifies the type of response to be passed back to the client, which in most cases is set as "code". The scope parameter defines the level of access that can be requested by the client.The scope parameter has the word "openid" incorporated to let the IdP know that this is an OIDC request and not an OAuth 2.0 request.
After the user enters their credentials and their identity is verified by the IdP, the IdP presents a consent page or dialogue box to the user. If the user does not consent to the terms mentioned, then they are taken back to the previous page and an access error is thrown. If the user consents to the mentioned terms, then the client's redirect URI page is presented along with an authorization code from the IdP. The client then pings the IdP to exchange the authorization code for the access token and the ID token. This process happens over the servers' back-channel, ensuring maximum security over the network.
The ID token helps the client understand the identity of the user who has just logged in. The access token is used if the client application needs to access more details about the user, their profile picture for instance. The relying party can now be assured that legitimate, authenticated users are accessing their application.
What are the different types of OpenID Connect flows?
The authorization code flow and implicit flow are built upon the OAuth 2.0 flow. The hybrid flow is specific to OIDC. Here are the different types of flows that OIDC uses:
Authorization code flow
This is the most commonly used OIDC flow. In this flow, the client receives an authorization code from the authorization endpoint or IdP, and later exchanges it for the ID and access tokens as discussed above.
This type of OIDC flow is used for end-user authentication by web applications and native apps that have a server-side component to keep the shared tokens and code confidential.
Implicit flow
In this OIDC flow, the client directly receives the ID token and access token from the authorization endpoint once the user is authenticated and provides consent. The token transaction here is considered to be a temporary, less-secure, front-channel process.
This type of OIDC flow is used by single-page applications, JavaScript applications, and user agent-based apps without back-end servers. Thus, the tokens are sent by the authorization endpoint directly using the front channel.
Hybrid flow
The hybrid flow is a combination of the previous two OIDC flows. Here, the authorization code and respective tokens are returned at the same time from the authorization endpoint. Like implicit flow, hybrid flow also exposes the tokens to the front channel. However, this flow is useful if the client needs to perform some additional information processing.
This type of OIDC flow is not very commonly used. It is only used by client applications which have bandwidth limitations and need separate tokens for the front and back channels.
Benefits of OpenID Connect
The OpenID Connect authentication protocol provides these benefits:
Simple
OIDC is a simple authentication protocol that can be easily integrated even with basic applications. It surpasses the earlier introduced authentication protocols such as SAML, OpenID 1.0, and 2.0, in terms of simplicity and usability.
Standardized
OIDC, having been built on top of the OAuth 2.0 protocol, has a standardized process flow. This arrangement also enables authorization and authentication functions to be performed using a single protocol.
Efficient
OIDC is considered to be an efficient protocol that uses the JWT format for the ID tokens. This format makes the tokens simple, readable and portable. It also supports a wide range of encryption and signature algorithms.
Flexible
The OIDC protocol supports both web applications and mobile applications, making it a popular single sign-on (SSO) protocol.
Secure
OIDC utilizes an encryption-based authentication framework that assigns security over the network.
What is SAML and how is it different from OpenID Connect?
Security assertion markup language (SAML) is an XML-based open standard that enables secure communication of identity data between an IdP and a service provider (SP). Here, the IdP performs user authentication and communicates the user's identity and authorization information to the SP. The SP trusts the IdP and authorizes that specific user to access the requested resource or application.
The SAML protocol helps authenticate and authorize a user to access a service. Employees in organizations with SAML-based applications can use a single set of credentials to access a dashboard so they receive direct access to other necessary applications without having to reauthenticate.
Though OIDC and SAML may seem similar, they differ in how communication is accomplished between the third-party application and the IdP.
SAML differs from OIDC in
the following ways
OIDC
- OIDC uses tokens written in JSON
- OIDC, both the access token and the ID token are issued to the application
- OIDC is more widely used because of its added efficiency and suitable advancements
SAML
- SAML uses tokens that are written in XML
- SAML, the application validates the signature and the certificate presented
- SAML was introduced much before OIDC and is still significant today
Enabling OpenID Connect SSO using ADSelfService Plus
ADSelfService Plus by ManageEngine offers SSO features to eliminate the need for multiple user credentials, to streamline the login experience of users, and to improve security. It uses AD credentials to verify users’ identities, and OU- and group-based policies to control access to various cloud applications.
ADSelfService Plus supports SSO through two widely used protocols—SAML, and OAuth with OpenID Connect. The SSO configuration for any OAuth with OpenID Connect-enabled custom enterprise application is supported. SP-initiated and IdP-initiated logins are available in ADSelfService Plus, and the supported scopes are openid, profile, email, and offline_access.
Learn more about ADSelfService Plus, and download a free, 30-day trial version to explore on your own. You can also schedule a free demo to see these features in action and get your questions answered by a solutions expert.
Thank you for your interest!
We have received your request for a personalized demo and will contact you shortly.
Fill out this form to schedule a personalized demo on SSO
Enable secure, one-click access to all enterprise applications
with SSO using ADSelfService Plus.