What Is CSU/DSU (Channel Service Unit/Data Service Unit)?

What is OpenID (OpenID Connect)?

ITN Technology News


What is OpenID (OpenID Connect)?

OpenID Connect is an open specification for authentication and single sign-on (SSO). It was built on top of the OAuth 2.0 protocol to add authentication and SSO capabilities.

OpenID Connect is a popular authentication protocol. It helps standardize the process for user authentication when users try to access a browser or mobile app.

First created in 2005, OpenID allows websites and authentication services to exchange security information in a standardized way. In February 2014, the OpenID Foundation launched a new version of the protocol called OpenID Connect. OpenID Connect builds on the OAuth 2.0 authentication framework to improve identity management, interoperability and support for many kinds of applications.

Benefits of OpenID Connect

OIDC provides a reliable and simple way to verify the identity of a user trying to access a digital service. The standard makes it seamless and secure to incorporate identity management into any kind of digital service, including the following:

Another benefit of OIDC is that it allows service developers and owners to obtain user profile information in an interoperable and safe manner. Since the protocol defines a set of (user) profile data categories, there’s no need for providers to store or manage user passwords. This minimizes the potential for data breaches involving credential theft.

OpenID Connect also allows end users to log in once to access multiple, disparate resources on and off the web. It enables convenient, secure SSO, which enhances the user experience and reduces website/app abandonment.

The specification, which has the backing of numerous cloud providers, such as Amazon, Google and Microsoft, is expected to pave the way for companies to replace their on-premise identity and access management (IAM) systems with cloud offerings.

In fact, organizations can use Microsoft’s IAM system (Entra ID) to authenticate user identities and then use OIDC to pass on the authentication to other apps. In doing so, they can enable SSO, so users access multiple apps by signing in only once with a single set of credentials.

OIDC also streamlines identity management in organizations. By providing OIDC-enabled SSO, they manage fewer identities and fewer identity management solutions. They can also keep track of changing permissions and apply access policies across multiple apps.

OpenID authentication flow example diagram
OpenID authentication flows define how the client application communicates with the OpenID provider to authenticate an end user. Some communications happen via the web browser and some happen directly between the client application and the OpenID provider.

How does OpenID Connect work?

OIDC leverages six key components to enable user authentication:

  1. Users: These are the people trying to access an application without creating a new set of credentials (or providing a set of existing credentials) and that must be authenticated before they can be granted access.
  2. Authentication: The process of confirming that the user really is who they say they are.
  3. Tokens: The JavaScript Object Notation, or JSON, web tokens (JWTs) containing a user’s identity data, such as their name, birth date, or email address, are used to authenticate the user.
  4. Client: The application or website that requests the tokens that are used to authenticate a user.
  5. Relying parties (RP): The applications that use OIDC providers to authenticate users.
  6. OIDC provider (also known as identity provider): The applications for which a user already has. login credentials and can therefore authenticate the user and pass the information to the relying party.

In addition, the protocol uses an Authorization Server to authenticate users as well as scopes that define what a user can do with their access.

Here’s how the authentication process works with OIDC:

  • The user opens the application they want to access.
  • They authenticate themselves, usually by providing their username and password.
  • The application redirects them to an identity provider.
  • The identity provider authenticates the user.
  • Post-authentication, the identity provider sends an identity token to the RP and redirects the user back to the RP.
  • The RP sends the token to the user’s device.
  • The user is logged into the RP application.
  • Once the process is complete, the user gets some indication on the application showing that they are logged in.
OpenID implicit authentication flow diagram
Here the client application uses implicit authentication flow to communicate with the OpenID provider to authenticate the user.

OpenID Connect use cases

OpenID Connect is a useful protocol for many scenarios.

Users can reuse their accounts on multiple applications without having to create a new set of credentials for each application. Simply integrating OIDC with an identity provider allows them to reuse existing accounts and leverage SSO.

The protocol can be used to create a hub of identity providers. This means that a provider can connect their application to a single identity provider (that works as a hub for other providers), so they don’t have to separately support multiple providers.

OIDC can work as a proxy for other protocols, including Security Assertion Markup-Language (SAML). This allows resource-constrained devices to seamlessly integrate with a SAML identity provider via OIDC.

OpenID Connect vs. SAML vs. OAuth 2.0

SAML is a standard that allows different security domains to exchange authentication and authorization data. This allows users belonging to one domain (Domain A) to consume the services of another domain (Domain B) without requiring Domains A and B to duplicate that user’s profile.

Like OIDC, SAML relies on digitally signed tokens that allow third-party applications to confirm user information and authenticate them on the fly. But unlike OIDC, SAML is heavily reliant on the Extensible Markup Language (XML) file format, which can be too heavy (and thus unnecessary) for applications that only need to authenticate users over low-speed connections or less robust devices.

The chief purpose of OIDC is to enable user authentication and provide users with one login to access multiple sites. It was developed to enhance the capabilities of OAuth 2.0, which is mainly about resource access and sharing. Also, OAuth 2.0 is an authorization framework unlike OIDC, which is an authentication framework.

Chart highlighting the differences in terminology between the OAuth 2.0 protocol and OpenID Connect.
Built on top of the OAuth 2.0 protocol framework, OpenID Connect enhances the capabilities of OAuth 2.O. Though similar, the two protocols have differences in terminology.

OAuth 2.0 enables client systems (e.g., scheduler apps) to use resource servers — for example, a website’s application programming interface (API) on behalf of resource owners (the end users). OAuth 2.0 was created to handle delegated authorization scenarios, although it is increasingly being used for user authentication.

Like OIDC, OAuth 2.0 uses an Authorization Server, albeit, not to authenticate users but to enable resource owners to decide whether they want to allow the client to do something on their behalf. OIDC also uses the term access token rather than identity token. The access token is what allows clients (third-party applications) to act on behalf of users (resource owners). It is also the artifact used by resource servers (APIs) to allow the client to perform the action on behalf of the resource owner.

OpenID Connect is the most popular federated standard built on top of OAuth 2.0. Explore how to use OpenID Connect for authentication. Also, API keys and tokens are two leading methods of access management. Learn the difference between API keys and tokens.