OIDC vs OAuth2: Key Differences

Picking the right user management flow for your application or platform has become extremely important today, with OpenID Connect (OIDC) and Open Authorization 2 (OAuth2) on most shortlists. But which one is better for your offering, if at all? Without further ado, let’s learn about the two methods and compare them.

What Is OpenID Connect (OIDC)?

OpenID Connect, commonly known as OpenID, is a specification for Single Sign-On (SSO) and user authentication purposes. 

OpenID, developed in 2005, lets authentication services and websites exchange security details in a standardized manner. In 2014, the OpenID Foundation developed a new version named OpenID Connect (OIDC). OpenID Connect strengthens the OAuth 2.0 authentication framework for better interoperability, identity management, and support for mobile apps in development. 

The aim of OpenID Connect is to let end-users log in just once to access disparate and multiple resources; on and off the internet. The specification, which has the support of various cloud providers, including Microsoft and Google, is believed to provide a way for organizations to replace their on-premise access management (IAM) and identity systems with cloud offerings.

Read more about the Top SSO Providers in the market today.

What Is OAuth2?

Open Authorization (OAuth) is an open standard authorization framework used for token-based authorization that is highly popular across the globe. 

OAuth flows provide end-user’s account details to third-party services, including Google and Facebook, without revealing the user’s account credentials to the third-party. It provides a go-between on behalf of the end-user, giving the third-party service an access token that authorizes the sharing of specific account information. The process of gaining the token is known as the authorization flow.   

OAuth 1.0 was initially released in 2007 as an authorization method for the Twitter API. In 2010, the IETF OAuth Working Group released the initial draft of the OAuth 2.0 protocol. As with the first OAuth, OAuth 2.0 allows users to provide third-party application access to web resources without revealing a password. However, it is an entirely new protocol and is not backward compatible with OAuth 1.0. 

New features include a new authorization code flow to allow for mobile apps, short-live tokens with long-lived authorizations, and simplified signatures.

Read more about OAuth vs JWT in our detailed comparison

How Does OAuth2 Work?

OAuth 2.0 is an authorization framework that lets end users grant access by one app to data stored by another, without having to re-enter their credentials. Read more about OAuth grant types in our dedicated article.

Its main focus is on secure authorization for a user who has already been authenticated and reducing friction as much as possible to improve the user experience. The image below shows an application (we’ll call it the “current application”) that uses the OAuth 2.0 protocol to enable users to register and sign up using their existing Google or Dropbox account.

The OAuth 2.0 protocol defines four roles:

• Resource Owner – The user that grants access to a protected resource
• Client – This is the “current application” pictured above
• Resource Server – The external app we need to integrate with, in the image above this can be Google or Dropbox.
• Authorization Server – The server responsible for authorizing which resources this user is allowed to access. 

In this example, Google and Dropbox provide both the authorization and resource server on the same API endpoint. But OAuth 2.0 is capable of contacting one server for authorization and then pull resources from a separate server. OAuth 2 supports four process flows. Let’s see the most common one, called Authorization Code Grant Type. 

This process flow works as follows:

1. The Client opens a browser window asking the Resource Owner’s permission to integrate with the external app
2. When the Resource Owner approves, the Client (current application) receives a verification code, which is a random text string
3. The Client contacts the Authorization Server, provides the verification code, and requests a secure Access Token
4. If the code is valid, the Authorization Server generates and sends an Access Token to the Client
5. The Client connects to the Resource server via an HTTP request, asking for the required resources, and providing the Access Token
6. If the Access Token is valid, the Resource Server allows the Client to access the protected information

How Does OIDC Work?

OpenID Connect (OIDC) is an authentication protocol that is currently supported by many popular web services, including Google, Paypal, Microsoft and Amazon. Its main focus is on authenticating a user to ensure they really are who they say they are. OIDC uses the OAuth 2.0 specifications to authorize resources on a target server. It extends OAuth 2.0, providing:

• Authentication with cryptographically signed tokens
• Sharing of user profile information
• Additional features that resolve security issues in OAuth 2.0

The OIDC protocol defines four entities:

• Relying Party – The “current application” in the aforementioned example 
• OpenID Provider – This is essentially an intermediate service that provides a one-time code to the Relying Party
• Token Endpoint – A web server that accepts the One-Time Code (OTC) and provides an access code that’s valid for an hour. The main difference between OIDC and OAuth 2.0 is that the token is provided using JSON Web Token (JWT), meaning it is digitally signed, and the Relying Party can verify the token has not been tampered with
• UserInfo Endpoint – The Relying Party communicates with this endpoint, providing the secure token and receiving information about the end-user 

OIDC vs. OAuth 2: Process Flows and Use Cases

OAuth 2.0 pays particular attention to authorization. It doesn’t deal with the particular aspects of how users are authenticated. It offers three process flows called “grant types”, which support the user cases outlined here (note that Implicit – the fourth OAuth process flow is not in use any more). 

• Authorization Code – This is used for mobile and browser-based applications and applications on web servers
• Password – This is used for first-party applications where users log in by entering their credentials directly
• Client Credentials – This is for providing access to applications when the user is not present (according to prior permission)

OpenID Connect supports both authentication and authorization, managing secure authentication of the end-user. It can also help with the handling of API access. OIDC offers three process flows that provide support for these use cases:

• Implicit – Used for single-page applications. Tokens are given directly to the Relying Party through a redirect
• Authorization Code – Used for native, single-page, and mobile web apps that need stricter security. It can also be safeguarded through the use of cryptographically-signed JWT tokens
• Hybrid – Allowing for both Authorization and Implicit Code. At first the ID token is returned to the Relying Party through a redirect URI, and then the Relying Party gives the ID token and asks for a temporary access token 

Related: OIDC vs SAML 

OIDC vs. OAuth 2: Setup and Ease of Use

Both OIDC and OAuth 2.0 are solid in terms of usability: 

• Both protocols are founded on JSON, which is supported by most mobile and web applications
• Both are simple to implement and don’t demand specific expertise
• Both are easy to scale and robust, even for mega-scale applications

OIDC vs. OAuth 2: Security

OAuth vulnerabilities surface in part because the OAuth specification is flexible and relatively vague in its design. There are a few mandatory components that are needed for the rudimentary functionality of every grant type, but most of the implementation is entirely optional. This encompasses many configuration settings that are needed to keep users’ information secure.

Put simply, there is a lot of opportunity for bad practices to arise. 

Another key concern with OAuth is the overall lack of built-in security features. Security is almost entirely dependent on developers making use of the correct combination of configuration options and putting their own additional security measures in place, including robust input validation. According to the type of grant, highly sensitive data is also transferred via the browser, which provides many malicious opportunities for cybercriminals. 

OpenID Connect specifications are more stringent than that of basic OAuth, which indicates that there is typically less potential for abnormal and potentially vulnerable implementations. That being said, it is simply a layer that sits on the OAuth. The OAuth service or client application might still be vulnerable to certain OAuth-based attacks.  

OIDC vs. OAuth 2: Limitations

OAuth 2 has the following limitations:

• Lack of a common format, which means that every service will require its own separate implementation
• During the process of user verification, you might have to make additional requests to obtain minimal user information. This might be resolved with the assistance of a JWT token, but this isn’t supported by all services
• When a token is stolen, a cybercriminal has access to the secure data for a given period of time. To limit this risk, you can use a token with a signature

OIDC has the following limitations:

• A newer solution, introduced only in 2019, resulting in lower adoption and industry implementation of best practices compared to plain OAuth
• HTTPS is the single layer of trust and encryption between an application and identity provider. In the unusual case of a compromised TLS/SSL certificate authority, the Single Sign-On (SSO) integration cannot be trusted

The Bottom Line

Both OpenID Connect and OAuth 2.0 have their place in the SaaS space, including user management solutions. But again a lot depends on your specific use case. If you are looking for an authorization solution, OAuth has the better track record. But you also need to keep in mind that it is less secure than OIDC, which also covers the authentication part.

Start For Free