Using JWT OAuth Token
OAuth and JWT are two very different topics when it comes to Authorization. OAuth is an open-standard authorization protocol, while JWT is an open-standard token format for secure information transmission between two parties. Let us dive deeper into both of these topics.
OAuth (Open Authorization) is an open-standard authorization protocol for access delegation. It describes how a service can allow other unrelated services to access its resources securely, without sharing any credentials.
Without even creating an account on Pinterest, we can sign with an existing Facebook or Google account. This is possible because of OAuth.
There are two versions of OAuth
- OAuth 1.0
- OAuth 2.0
Let’s discuss OAuth 2.0 in detail.
OAuth 2.0 Roles
The following are the four roles of OAuth 2.0:
- Resource owner: It refers to the user(a person) who can grant access to a protected resource.
- Resource server: It refers to a protected API/service that needs to be protected with OAuth. It can respond to protected resource requests.
- Authorization server: It refers to the server that authorizes the user and client-server. It supplies access tokens to the client application after authorization is done.
- Client application: It refers to a third-party application that makes requests to access protected resources on the resource server.
OAuth 2.0 Endpoints
Endpoints provide the Client application with the ability to communicate with the Authorization server via URLs.
- Authorization endpoint: To authorize client application
- Token endpoint: To request a new access token
- Token revocation: To delete any access token
- Token validation: To validate the access token
Client ID, Client Secret, and Redirect URI
A third-party application must be registered in the authorization server associated with the resource server before requesting access to resources. After registration, client-server gets client_id and client_secret.Then, whenever the client-server requests the protected resources, it needs to authenticate itself by using the client id and client secret to the authorization server. During the registration, the client also registers a redirect URI. When a resource owner has successfully authorized the client application via the authorization server, the resource owner is redirected back to the client application to the redirect URI.
The resource owner, along with the authorization server, gives an authorization grant to the client application. The OAuth grant type determines the exact sequence of steps involved in the OAuth process and specifies how the client application communicates with the authorization server.
Following are the various authorization grant types
- Authorization Code
- Resource Owner Password Credentials
- Client Credentials
Let’s discuss in detail the Authorization Code, which is the most common type of OAuth grant.
In the case of this type of Authorization grant, the client application, instead of requesting authorization directly from the resource owner, directs the resource owner to an authorization server. The resource owner is then redirected back to the client app with the authorization code. The client app will then send the authorization code back to the Authorization server for getting an access token in return. The client app can use this access token to make requests for accessing protected resources.
- The user/ resource owner accesses the client application.
- The client app asks the user to log in to the client app via an authorization server. (For ease of understanding, consider the client app Pinterest and the authorization server to be Facebook).
- The user/resource owner is then redirected to the authorization server by the client app. The client application sends its client ID to the authorization server, so it knows which application is trying to access the protected resources.
- After successful login, the user is asked if they want to grant access to their resources to the client application. If the user accepts, the user is redirected to the client application to a specific Redirect URI.
- The Authorization server also sends the Authorization code.
- When redirected back to the client application, the authorization server sends the user to a specific redirect URI.
- When the redirect URI in the client application is accessed, the client application connects directly to the authorization server. The client app sends the authorization code and its client ID and client secret to the Authorization server.
- The authorization server sends back an access token.
- The client application can now use the access token to request resources from the resource server.
JWT( JSON Web Token) is an open standard(RFC 7519) used to securely transmit information between two parties as a JSON object.
- Compact: They are small enough to be sent via URL, a POST request, HTTP headers causing it to be very fast.
- Self-contained: It contains information about the user so that multiple lookups in the database is avoided.
- Security: JSON Web Tokens securely transmit information between two parties using public or private key pairs. It can be made sure that content has not been tampered with as the signature is calculated using the header and the payload section of JWT.
A JSON Web Token consists of 3 parts separated by a period.
|JWT = header.payload.signature|
Header: A header is a JSON object containing two fields - one is ‘alg’ which specifies the algorithm( like HMAC, SHA256, RSA, HS256, etc.) used for encoding.The second part is ‘typ’, which specifies the token type. For example:
Payload: A payload is a JSON object containing session data called claims. Some of the standard claims are Issuer(iss) , Subject(sub), expiration time(exp) of the token etc.
An example payload can be:
"name": "John Doe",
Signature: It is the most essential part of JWT. It is calculated by encoding header and payload using Base64url Decoding and concatenating the two with a period. Then this concatenated string is given to the cryptographic algorithm specified in the header.
For example, if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way,
base64UrlEncode(header) + "." +
Finally, these three parts are encoded individually using Base64url encoding and concatenated to produce the final JWT.
How does JWT work?
- When users try to sign in using their credentials, a JSON Web Token is returned from the server to the client if the authentication is successful.
- Next, whenever the user wishes to access a protected resource, the client has to send a copy of JWT on the Authorization header while making the request.
- The server then checks the JWT signature, and if the signature matches the defined signature, it sends a response to the client.
Using JWT with OAuth2
JSON Web Tokens can be incorporated with OAuth2 as it does not specify the format of tokens.
Instead of returning access tokens from the Authorization Server, the Server can return JSON Web Tokens to the Client server. This can be a typical use case of JWT with OAuth2.
However, we should keep in mind that using OAuth2 with JWT can not increase the security of an application but can increase the performance by many folds.
Frequently Asked Questions
- What are the main differences between JWT and OAuth?
Ans: The main difference between the two is that - JWT is a token format, and OAuth is an authorization protocol.
- Can JWT be used with OAuth2?
Ans: Yes, JWT can be used with OAuth since it does specify the format of tokens.
To sum up this blog, we learned about OAuth, OAuth 2.0 roles, endpoints, along with Authorization grant. We also went through the features and structure of JWT and how it works.
We hope you have understood OAuth and JWT by the end of this article. Happy Learning Ninja!