Best Practices for Handling JWTs
Tags: jwt, security, api, cybersecurity
Published: 2023-01-11 12:34:43

Even though JSON Web Tokens (JWT) are widely used in the OAuth and OpenID protocols, maintaining a high level of security while using them is not always easy. This article will focus on some best practices for handling JWTs so that you can maintain a high level of security in your applications. 

## What is a JWT? 

- JWTs are not protocols, they are message formats.
- They are used to pass messages between two parties, e.g., a client and a server, or between services.
- A JSON Web Token has a form of a string divided into parts which are base64 encoded and separated by dots. 
- A JWT can either be a JWS (a signed token) or a JWE (an encrypted token). These types of tokens define the parts that the JSON Web Token will consist of. 
- Most often JWTs are used as Access Tokens or ID Tokens (but they can also be used in other scenarios as well).

## JWT Best Practices
 
**Protect Valuable API Data in Access Tokens** 

When JWTs are issued to your clients to be used as Access Tokens, client developers are able to access the data in the token.  In such cases developers can start using the data from JWTs in their applications which can cause issues if you decide to change the structure of the data in the JWT. As the token can easily be accessed or read, personal information about users can also be easily leaked and valuable API data can become prone to cyber attacks. Either avoid adding sensitive data to access tokens or utilise a pattern like the [Phantom Token](https://curity.io/resources/learn/phantom-token-pattern/), where the data is concealed by an opaque token.

**JWTs and Algorithms**

Encrypted and signed tokens always contain an `alg` claim in the header to show which algorithm has been used. When verifying and decrypting tokens it is considered a best practice to check the value of this claim against a list of algorithms that your system accepts and which are verified to be secure. If the `alg` claim contains a `none` value, make sure that you know both the identity of the issuer of the token and of the client that uses the token before proceeding.

**Always Validate an Incoming JWT**

Another best practice is to always validate an incoming token. This should be done even when a service is only accessible on an internal network, to prevent situations where someone manages to make requests from inside the network. Many times when services are moved to a public domain the security measures are overlooked, thus it’s important to have them properly protected from the beginning. 

**Verify the Issuer**

Always check the issuer of the JWT to make sure that you can trust them by checking the `iss` claim. This is especially important when downloading the keys needed to validate / decrypt the tokens. Make sure to confirm that any cryptographic keys used to sign or encrypt the token belong to the issuer. The verification of the issuer depends on the implementation of the JWT. For example, when using OpenID Connect the issuer should be an HTTPS URL. This makes it easier to confirm the ownership. 

### Conclusion

In this article we have explored a few best practices when using JWTs. It's important to remember that JWT safety depends greatly on how the tokens are implemented and used. At Curity, we have written a complete guide on [how to keep your JWTs secure](https://curity.io/resources/learn/jwt-best-practices/), following best practices. Make sure to also check any changes in the RFCs which talk about the good practices for [JWTs: in RFC 8725 JSON Web Token Best Current Practices](https://www.rfc-editor.org/rfc/rfc8725) and in [RFC 7518 JSON Web Algorithms (JWA)](https://www.rfc-editor.org/rfc/rfc7518).


**Related content:**

[Self-contained JWTs - Curity](https://curity.io/resources/learn/self-contained-jwts/)
[JWT Signatures and EdDSA - Curity](https://curity.io/resources/learn/jwt-signatures/)