This is the Trace Id: df8322bbfb36bd09ab38d9c1d0fab879
Skip to main content
Microsoft Security
A worker in an industrial setting uses a tablet to review information

What is OIDC?

Learn about OpenID Connect (OIDC), an authentication protocol that verifies user identities when they sign in to access digital resources.
Learn more about Microsoft Entra ID

OpenID Connect (OIDC) defined

OpenID Connect (OIDC) is an identity authentication protocol that is an extension of open authorization (OAuth) 2.0 to standardize the process for authenticating and authorizing users when they sign in to access digital services. OIDC provides authentication, which means verifying that users are who they say they are. OAuth 2.0 authorizes which systems those users are allowed to access. OAuth 2.0 is typically used to enable two unrelated applications to share information without compromising user data. For example, many people use their email or social media accounts to sign in to a third-party site rather than creating a new username and password. OIDC is also used to provide single sign-on. Organizations can use a secure identity and access management (IAM) system like Microsoft Entra ID (formerly Azure Active Directory) as the primary authenticator of identities and then use OIDC to pass that authentication to other apps. This way users only need to sign in once with one username and password to access multiple apps.

Key components of OIDC

There are six primary components in OIDC:
 
  • Authentication is the process of verifying that the user is who they say they are.
  • A client is the software, such as website or application, that requests tokens that are used to authenticate a user or access a resource.
  • Relying parties are the applications that use OpenID providers to authenticate users.
  • Identity tokens contain identity data including the outcome of the authentication process, an identifier for the user, and information about how and when the user is authenticated.
  • OpenID providers are the applications for which a user already has an account. Their role in OIDC is to authenticate the user and pass that information on to the relying party.
  • Users are people or services that seek to access an application without creating a new account or providing a username and password.

How does OIDC authentication work?

OIDC authentication works by allowing users to sign in to one application and receive access to another. For example, if a user wants to create an account at a news site, they may have an option to use Facebook to create their account rather than creating a new account. If they choose Facebook, they are using OIDC authentication. Facebook, which is referred to as the OpenID provider, handles the authentication process and obtains the user’s consent to provide specific information, such as a user profile, to the news site, which is the relying party.

ID tokens

The OpenID provider uses ID tokens to transmit authentication results and any pertinent information to the relying party. Examples of the type of data that are sent include an ID, email address, and name.

Scopes

Scopes define what the user can do with their access. OIDC provides standard scopes, which define things such as which relying party the token was generated for, when the token was generated, when the token will expire, and the encryption strength used to authenticate the user.

A typical OIDC authentication process includes the following steps:
 
  1. A user goes to the application they wish to access (the relying party).
  2. The user types in their username and password.
  3. The relying party sends a request to the OpenID provider.
  4. The OpenID provider validates the user’s credentials and obtains authorization.
  5. The OpenID provider sends an identity token and often an access token to the relying party.
  6. The relying party sends the access token to the user’s device.
  7. The user is given access based on the information provided in the access token and relying party. 

What are OIDC flows?

OIDC flows define how tokens are requested and delivered to the relying party. A few examples:
 
  • OIDC authorization flows: The OpenID provider sends a unique code to the relying party. The relying party then sends the unique code back to the OpenID provider in exchange for the token. This method is used so that the OpenID provider can verify the relying party before sending the token. The browser can’t see the token in this method, which helps keep it secure.
  • OIDC authorization flows with PKCE extension: This flow is the same as the OIDC authorization flow, except that it uses a public key for code exchange (PKCE) extension to send communications as a hash. This reduces the chances that the token will be intercepted.
  • Client credentials: This flow provides access to web APIs by using the identity of the application itself. It’s typically used for server-to-server communication and automated scripts requiring no user interaction.
  • Device code: This flow allows users to sign in and access web-based APIs on internet-connected devices that do not have browsers or have a poor keyboard experience, such as a smart TV.
Additional flows, such as the OIDC implicit flow, which is designed for browser-based applications, are not recommended because they are a security risk.



OIDC vs. OAuth 2.0

OIDC was built on top of OAuth 2.0 to add authentication. The OAuth 2.0 protocol was developed first and then OIDC was added to enhance its capabilities. The difference between the two is that OAuth 2.0 provides authorization, while OIDC provides authentication. OAuth 2.0 is what allows users to gain access to a relying party, using their account with an OpenID provider, and OIDC is what allows the OpenID provider to pass along a user profile to the relying party. OIDC also allows organizations to offer their users single sign-on.



Benefits of OIDC authentication

By reducing the number of accounts that users need to access apps, OIDC offers several benefits to both individuals and organizations:

Reduces the risk of stolen passwords

When people need to use multiple passwords to access the apps they need for work and their personal life, they often pick easy-to-memorize passwords, such as Password1234!, and use the same one across several accounts. This increases the risk that a bad actor will guess a password. And once they know the password to one account, they may be able to access other accounts too. By reducing the number of passwords that someone has to memorize, it increases the odds that they will use a stronger, more secure password.

Enhances security controls

By centralizing authentication in one app, organizations can also safeguard access across several apps with strong access controls. OIDC support two-factor and multifactor authentication, which require people to verify their identity using at least two of the following:
 
  • Something the user knows, typically a password.
  • Something they have, such as a trusted device or token that’s not easily duplicated. 
  • Something the user is, like a fingerprint or face scan.
Multifactor authentication is a proven method for reducing account compromise. Organizations can also use OIDC to apply other security measures, like privileged access management, password protection, login security, or identity protection, across multiple apps.

Simplifies the user experience

Signing into multiple accounts throughout the day can be time consuming and frustrating for people. Plus, if they lose or forget a password, resetting it can further disrupt productivity. Businesses that use OIDC to provide their employees’ single sign-on help ensure their workforce is spending more time on productive work rather than trying to gain access to apps. Organizations also make it more likely that customers will sign up for and use their services if they allow individuals to use their Microsoft, Facebook, or Google account to sign in.

Standardizes authentication

The OpenID Foundation which includes high-profile brands like Microsoft and Google, built OIDC. It was designed to be interoperable and supports many platforms and libraries, including iOS, Android, Microsoft Windows, and the major cloud and identity providers.

Streamlines identity management

Organizations that use OIDC to provide single sign-on for their employees and partners can reduce the number of identity management solutions they need to manage. This makes it easier to keep track of changing permissions and allows administrators to use one interface to apply access policies and rules across multiple apps. Companies that use OIDC to allow people to sign in to their apps using an OpenID provider reduce the number of identities they need to manage at all.

OIDC examples and use cases

Many organizations use OIDC to enable secure authentication across web and mobile apps. Here are a few examples:
 
  • When a user signs up for a Spotify account, they are offered three choices: Sign up with Facebook, Sign up with Google, Sign up with your email address. Users who choose to sign up with Facebook or Google are using OIDC to create an account. They will be redirected to whichever OpenID provider they selected (either Google or Facebook) and then once they’ve signed in, the OpenID provider will send Spotify basic profile details. The user doesn’t have to create a new account for Spotify and their passwords remain protected.
     
  • LinkedIn also provides a way for users to create an account using their Google account rather than creating a separate account for LinkedIn.
     
  • A company wishes to provide single sign-on to employees that need to access Microsoft Office 365, Salesforce, Box, and Workday to do their job. Rather than requiring employees to create a separate account for each of those apps, the company uses OIDC to provide access to all four. Employees creates one account and each time they sign in, they get access to all the apps they need for work.

Implement OIDC for secure authentication

OIDC provides an authentication protocol for simplifying sign-in experiences for users and enhancing security. It’s a great solution for businesses that want to encourage customers to sign up for their services without the hassle of managing accounts. It also empowers organizations to offer their employees and other users secure single sign-on to multiple apps. Organizations can use identity and access solutions that support OIDC, such as Microsoft Entra, to manage all their identities and authentication security policies in a single place.



Resources

Learn more about Microsoft Security

  1.
A man and woman sitting at a table, with the woman writing on a book and a laptop visible.

Microsoft Entra ID

Securely connect employees, customers, and partners to their apps, devices, and data with a cloud identity and access management solution.
Learn more about Microsoft Entra ID
A person sitting at a desk using a laptop.

Microsoft Entra ID Governance

Automatically ensure that the right people have the right access to the right apps and services.
Learn more about Microsoft Entra ID Governance
A woman looking at her mobile phone.

Microsoft Entra Verified ID

Provide decentralized identities with a managed verifiable credentials service based on open standards.
Learn more about Microsoft Entra Verified ID
A group of three people in a bright office, smiling and engaged as they look at a laptop held by one person.

Microsoft Entra Workload ID

Manage and secure the identities granted to apps and services.
Learn more about Microsoft Entra Workload ID
Back to Related products section
FAQ

Frequently asked questions

  • OIDC is an identity authentication protocol that works with OAuth 2.0 to standardize the process for authenticating and authorizing users when they sign in to access digital services. OIDC provides authentication, which means verifying that users are who they say they are. OAuth 2.0 authorizes which systems those users are allowed to access. OIDC and OAuth 2.0 are typically used to enable two unrelated applications to share information without compromising user data.
  • Both OIDC and security assertion markup language (SAML) are identity authentication protocols that allow users to securely sign in once and access multiple applications. SAML is an older protocol that has been widely adopted for single sign-on. It transmits data using XML format. OIDC is a newer protocol that uses JSON format to transmit user data. OIDC is gaining in popularity because it’s easier to implement than SAML and works better with mobile applications.
  • OIDC stands for OpenID Connect protocol, which is an identity authentication protocol used to enable two unrelated applications to share user profile information without compromising user credentials.
  • OIDC was built on top of OAuth 2.0 to add authentication. The OAuth 2.0 protocol was developed first and then OIDC was added to enhance its capabilities. The difference between the two is that OAuth 2.0 provides authorization, while OIDC provides authentication. OAuth 2.0 is what allows users to gain access to a relying party, using their account with an OpenID provider, and OIDC is what allows the OpenID provider to pass along a user profile to the relying party. This functionality also allows organizations to offer their users single sign-on. The OAuth 2.0 and OIDC flows are similar except they use slightly different terminology.

    A typical OAuth 2.0 flow has the following steps:
     
    1. A user goes to the application they wish to access (the resource server).
    2. The resource server redirects the user to the application where they have an account (the client).
    3. The user signs in using their credentials for the client.
    4. The client validates the user’s access.
    5. The client sends an access token to the resource server.
    6. The resource server grants the user access.
       
    A typical OIDC flow has the following steps:
     
    1. A user goes to the application they wish to access (the relying party).
    2. The user types in their username and password.
    3. The relying party sends a request to the OpenID provider.
    4. The OpenID provider validates the user’s credentials and obtains authorization.
    5. The OpenID provider sends an identity token and often an access token to the relying party.
    6. The relying party sends the access token to the user’s device.
    7. The user is given access based on the information provided in the access token and relying party.
  • The OpenID provider uses ID tokens to transmit authentication results and any pertinent information to the relying party application. Examples of the type of data that are sent include an ID, email address, and name.

Follow Microsoft Security