OAuth2 vs JWT – What’s the Difference (Explained)
OAuth2 vs JWT – What’s the Difference?. Authorization is a necessary component of every user-based application. It is the process of granting access to the application to access the required resources. Two major protocols that are widely used for web authorization are OAuth 2.0 and JSON Web Tokens.
This article will discuss OAuth2 vs JWT and their differences.
What is OAuth2 (2.0) ?
OAuth 2.0 is an open standard for web authorization. It was developed in 2006 as an open standard for API access delegation. Over time the standard became popular and more widely adopted by companies and sites. For example, in April 2010, all third-party Twitter applications were required to use OAuth. OAuth2 framework was later published, which considers additional use cases and extensibility requirements of the IETF community.
However, OAuth 2.0 is not backward compatible with OAuth 1.0. Major tech companies such as Facebook, Google, and Microsoft use OAuth 2.0 as the authorization of their APIs.
What is JWT - JSON Web Token ?
JWT is an internet standard for transferring data over the internet securely. A typical JWT consists of 3 components; the header, the payload, and the signature. Header is used to identify which algorithm is used to generate the signature. A payload is a set of claims that are being transferred. JWT defines the set of valid claim names, there are seven standard claim names, but custom claims can be defined as well. The last part of the JWT is the signature. It is used to securely validate. The signature is calculated by encoding the header and payload using Base64url encoding. The three parts are encoded separately and then concatenated using periods (“.”).
OAuth2 vs JWT
Opaque Auth Token
Unlike the JWT, opaque tokens are not meant to be read by anyone hence only the issuer knows the format. The opaque token is a primary key that references a database entry with the data instead of storing user identity and claims in the token. Since the roles are read directly from a database, roles can be modified, and as soon as the modifications propagate to the backend, the user can see the new roles.
OAuth Grant Types
These OAuth grant types are also often referred to as OAuth flows. OAuth Grant type determines the sequence of steps in the authentication OAuth process and how the client application will interact with the server in each stage. The first stage is the authentication request. Next, the client application sends a request to the service asking for permission to access the requested data. The next stage is user login, where the user provides the login credentials. If the login is granted, the access token is sent to the client.
Using the access token, the client cannot request data from the server.
Tokens
Usually, JSON Web Tokens are great for limiting database lookups. Oauth2 tokens are great for accessing user data.
Access Tokens
An access token checks whether or not the bearer of the token is allowed to access the thing they are trying to access. The access token does not necessarily have to have a user ID. All it needs to encode is whether or not the thing that has the access token can access the API. That is why it is called a Bearer Token. The bearer of the token can access the API.
In some cases, that is by actually encoding the values into the token itself if your access token is, for example, a JWT, or it might be something that is just stored or cached in some database associated with your random string token. The important thing is as far as the application is concerned, the application does not care what the token means. It just knows that it can use the token to make the API call.
Refresh Tokens
A refresh token is a special type of token used only against the authorization server. To have more security, an access token typically has a short lifetime so that even if the attacker gets hold of it, it will not last long. But that causes problems for the client. If there were only access tokens, the client has to make the authorization request to the authorization server in which the resource owner is involved. If there is no resource owner at the time, there can be a lot of problems. Besides, it will be too annoying for the resource owner even if there were.
The refresh tokens are there to solve the problem. It is a long lifetime token only used against the authorization server. Since it is only used against the authorization server, its risk of being stolen is substantially lower. The client can use it against the token endpoint to get a new access token. It refreshes the access token; that is why it is called refresh token.
Stateless Authentication Mechanism
Maintaining the system’s state has always been a challenge for the developers. Stateless applications are more suited for functional approaches as they are better for multi-threading and concurrency. Maintaining a state at a large scale would be a huge computational overhead. Stateless authentication requires eliminating sessions and session tokens.
In JWT, when a user is authenticated, the server generates a base64 JWT access token rather than a session token and returns it to the client, which now can use the access token until it expires. In this way, the server no longer has to maintain which users are authenticated, and it just needs to check if the access token sent with the request is valid or not.
Multi Application Authentication
OAuth 2.0 provides SSO for multi-application authentication that provides single sign on for applications. However, OAuth 2.0 does not perceive how the communication between the resource server and authentication server occurs and does not specify in what form the user expects the output. The general workflow is that the first client sends a login request to the authentication server. Once the authentication is complete, the access code is sent back to the client. Finally, the client sends the access code to the resource server to execute its request.
On the other hand, in a multi-application authentication with JWT, access code can be shared between the applications if all the platforms share the same secrets.
Claims
JWT claims are a piece of knowledge asserted about a subject, and these are represented in JSON format. There are two types of claim; reserved and custom. Reserved claims are defined by JWT specifications, while custom claims are defined and named by the user. There are two types of custom claims; public claims and private claims. Public claims are used to store non-sensitive information such as names. Private claims are used to store sensitive information such as social security numbers. OAuth also provides claims like JWT as name-value pairs but provides added functionality in the form of scopes.
OAuth2 vs JWT – What’s the Difference Final Thoughts
OAuth2 vs JWT, Both systems have their particular use cases and advantages. While JWT is excellent for API authentication and server-to-server authorization, OAuth 2.0 takes the lead in session management. JWT tokens are stateless; hence the information is not stored on the server site, but a major drawback is that the token expires after a pre-defined duration; hence it is not suitable for applications in which the session should persist.
On the other hand, JWT is not as secure from a security standpoint because changing the password would not expire the previously generated tokens. Hence to figure out which must be better, we must select the one that will benefit our particular use case rather than just looking at the general features of the system.
