API Security – OpenID, OAuth And JWT In Detail

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.

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.

Understanding 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.

What is an OAuth Protocol?

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.

OAuth stands for Open Authorization. It is built strictly for Access Authorization.

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.

The entire flow in OAuth can happen as below:

1. User U wants the application Tc to access data from another application G+ which holds his data (a data provider).
2. Tc redirects user U to G+.
3. G+ prompts user U to validate himself against the user store of G+.
4. User enters his credentials in G+ (authentication).
5. G+ prompts a screen to User asking his permission to let Tc access his data from G+ (consent screen). User grants permission.
6. G+ redirects to Tc with an access information (a token) which holds the key to User U’s data in G+.
7. Tc requests data from G+ by means of a REST API, along with the token of User U.
8. G+ validates the token and returns data to Tc.

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).

Properties of OAuth2 / OAuth

1. OAuth is strictly an authorization protocol, although generic in implementation.
2. This protocol was brought to bring in uniformity among the identity providers (IDPs) available in the market, previously these providers had different implementations of authorization among one another, and the resultant access information was also bit different in each provider. OAuth solves these issues by defining guidelines of authorization should happen and what should be returned.
3. Although OAuth defines the process, the token specification was not made. This means that the OAuth token can be of different formats, structures and crypto signatures for each IDP.
4. An OAuth token doesn’t necessarily contain any user information, although non-application-specific information like userId or objectId can be passed.

What is an OpenID Protocol?

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).

OpenID stands for Open Identity. It can be used for User Authentication. It has three revisions – OpenID, OpenID 2 and the latest, OpenID Connect (OIDC).

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:

1. User U needs to signin to an application Tc to access his profile. The application Tc provides him with three provider options to Identity: G+, Tw or Hm. User clicks on G+.
2. The application Tc redirects user to another application G+, which prompts his user credentials.
3. User enters his credentials and are validated against G+ userstore.
4. On success, the G+ redirects back to Tc with a special token (authentication).
5. Tc receives the token and reads the information, validates against its own userstore and loads the user profile available within it’s system.

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.

Properties of OpenID Connect

1. OpenID Connect (the latest version of OpenID after OpenID and OpenId2) is written on top of OAuth2 protocol with authentication in mind.
2. This protocol helps in seamless integration of User Identities across different application platforms. This helps in single sign on (SSO) experiences.
3. The protocol defines the token to be returned as an id_token in contrast to the access_token issued by OAuth2. To help keeping in compliance with the OAuth2 protocol, OpenID also returns an access_token and a refresh_token which can be used to reissue access_token when the previous token expires.
4. An id_token contains data about the user in question apart from other information, which doesn’t require another request for information access.
5. The specification defines what information needs to be passed in what, such as:

• sub: unique user identifier
• iss: the identity provider or issuer of token
• aud: the client application registered under the provider for which the token was intended to
• What is a JWT? Where does this Fit in?

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:

JWT is a compact url-safe means of representing clains to be transferred between two parties. The claims in a JWT is a JSON (JavaScript Object Notation) Object that is used as the payload of a JSON Web Signature (JWS) or a plain text of JSON Web Encryption (JWE) structure enabling claims to be digitally signed or MACed or encrypted.

A typical JWT token contains three segments:

• Header which contains information about the type of token and the algorithm being used to encrypt
• Payload which contains the claim information in the form of an encrypted JSON object
• Signature which is an offset attached which contains a verified signature for token integrity

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 as well.

Basically the protocols OpenID or OAuth use a JWT Token as their vehicle of functionality.

One can inspect a given JWT Token for its contents by using a Validator tool (such as one available in jwt.io) where once pasted and parsed, we can observe the sections mentioned above, along with the contents of the payload.

Now this leads to a new question, if one can open up a JWT token and view its contents how can it be used for API security and authentication?

It can, because every token has a fixed lifetime post which the token is deemed invalid. It is also recommended to NOT PASS ANY SENSITIVE INFORMATION in the token.

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.