Our modern identity services are exposed through developer-friendly APIs, SDKs and Low-Code services to deliver the scale and performance required for any and all customer use cases.
Featured Blog Post:
It’s notoriously difficult to implement an account recovery process that prevents fraud without creating more friction for customers who are already locked out and frustrated. In a US consumer...
In some situations, one application may need access to data held by another application. A common example is a list of contacts used to send emails, texts, etc. to a user’s friends and family. One option for sharing this access is providing one application with the user’s credentials for the other. While this makes it possible to access the required data, it also creates significant security issues. OpenID Connection (OIDC) and OAuth2 make it possible to enable data sharing between applications without sharing user credentials.
Before diving into the details of OIDC vs. OAuth2, it’s important to understand the difference between user authentication vs. authorization. Authentication is proving a user’s identity to a service. This is accomplished using passwords, biometrics, etc.
Authorization uses the authenticated identity of a user to determine what they should be able to access. With the knowledge that you are you, a system can then determine if you should be able to access a particular system, and, if so, what level of access you should have.
OAuth2 is an authorization standard defining a framework for sharing account information about a user between parties without revealing their credentials. For example, if you want to share your contacts list with a website so that it can send emails on your behalf and click on a “Sign In with Google” button, then you’re using OAuth2.
OAuth2 focuses on authorization, not authentication. The assumption is that Google, Facebook, etc. has performed strong authentication and is confident about a user’s identity. OAuth2 provides one service the ability to access data about a user collected by another without the need for the user to log in again.
The OAuth2 framework has a few different process flows or “grant types”. It defines the following four roles, which, under the Authorization Code Grant Type, perform the following functions:
OpenID Connect is designed to provide a common format for exchanging user authentication information between authentication services and websites. It provides specifications for Single-Sign On (SSO) and user authentication flows, making it easier to integrate strong user authentication into websites and mobile apps.
With OIDC, users can log in once and take advantage of SSO to gain access to both Internet-based and non-Internet resources without needing to log in again. OIDC is supported by Microsoft, Google, and other cloud providers.
OIDC is an extension of OAuth2 that focuses on user authentication rather than user authorization. Once OIDC authenticates a user, it uses OAuth2 specifications to perform authorization.
Like OAuth2, OIDC includes four parties:
OAuth2 and OIDC are closely-related protocols; however, they have some significant differences. Including:
OAuth2 and OIDC both have their pros and cons. OAuth2 is more established but lacks support for authentication and has weaker security. By adding OIDC, an application is reliant on a less widely-adopted protocol but adds authentication and security benefits.
