One of the first level components of an application is the User Identity Management and Access Management. The basic rules of challenging a user's identity and then validating the user's access to a resource result in the two terms authentication and authorization. And when we talk about authentication and authorization, we talk about the most widely used authentication and access management protocols these days; the OAuth and OpenId.
And what is the difference between these two mechanisms? Let's discuss about these in this article.
The basics - Authentication and Authorization:
Authentication and Authorization are two terms used interchangeably in context of Identity management, but serve two different purposes. Authentication can be defined as validating the existence of a user against a system. The user secret information or the credentials are challenged against a User Store and basing on the result we consider the user as authenticated or not authenticated. Authorization comes a bit later to authentication, which can be defined as verifying whether the user is permitted to use a resource in a system by means of any secret information and granted access.
Authentication happens before Authorization, and Authorization requires Authentication.
The Guiding Protocols - OAuth and OpenId:
OAuth is a protocol defined which explains how a user should be authorized by a system. It was principally developed for Authorization but is generic to implementing for a larger purposes like API management and others. Let's take an example of a application Tc which needs to access a user's data U from another application G+ which is the data provider.
Now the entire flow in OAuth can happen as below:
The above flow is most common among today's applications which read an authenticated user's data among one another. The OAuth is now succeeded by OAuth2 which adds more features and tries to unify the user's authorization mechanism among all the auth providers (IDPs).
Some properties of OAuth2 / OAuth:
OpenId on the other hand is used for authenticating a user against a user store. The OpenId was developed as a profile over the existing OAuth2 protocol, which can be used for authentication flows using signed JSON Web Tokens (JWT). Let's take an example of an application Tc which needs to authenticate a user using his credentials of G+, another provider application.
The authentication flow in this case can happen using OpenId as follows:
The above flow is most common amongst the mobile and web applications which delegate their user identity management to available third-party identity providers through third-party logins, such as social logins. In these scenarios, the identity providers return a special token which contains user information necessary for the applications to authenticate the user in question.
Some properties of OpenId Connect:
The JWT jargon:
Now most of the developers confuse among the terms OAuth, OpenId and JWT. While the first two have been discussed in detail above, let's talk a bit about JWTs as well. The JSON Web Tokens or JWT are defined by the standard as follows:
A typical JWT token contains three segments:
The JWT tokens are typically used in OpenId connect authentication flows, while most of the popular Identity Providers have moved on to use JWT format for Authorization token formats. These are a standard now followed in the REST APIs and help in seamless integration among several data and identity providers in a unified communication language spoken.
These are some of the basic differences between the protocols OAuth and OpenID which form the base of today's Identity Management and SSO.