JWT or Opaque Token : What is the best choice for M2M?

JWT or Opaque Tokens can serve both as authentication mechanisms for Machine to Machine (M2M) communications. But what is the best choice between each solution? In this brief article, we will try to answer this question.

First of all, we should define what are JWT and Opaque Token.

OAuth (Client Credentials)

In this article, we'll use OAuth for both JWT (JSON Web Tokens) and Opaque Tokens. We should start defining what is OAuth and what grant_type to use for Machine to Machine communications.

OAuth (Open Authorization) is a protocol used for authorization, allowing to grant third-party applications limited access to resources. It enables secure access to APIs by providing a way for clients (applications) to obtain access tokens from authorization servers, which are then used to authenticate and access protected resources.

The Client Credentials grant_type is one of the authorization grant types defined by OAuth. It is typically used when the client (application) is acting on its own behalf, rather than on behalf of a user. This grant type is suitable for machine-to-machine communication or cases where no user involvement is required.

POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=abcd1234
&client_secret=client_secret
&scope=read write
&audience=api_server

In this example, the client sends a POST request to the token endpoint of the authorization server with the grant_type=client_credentials parameter. The client also includes its client_id and client_secret as part of the request. The authorization server validates the client credentials and issues an access token if the client is authorized.

The response from the authorization server includes an access token that the client can use to authenticate and access protected resources.

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
  "token_type": "Bearer",
  "expires_in": 86400
}

JWT

A JWT (JSON Web Token) is a compact, self-contained mechanism for securely transmitting information between parties as a JSON object. In the context of API authentication, a JWT typically serves as an authentication token. It is digitally signed to verify its authenticity and integrity.

Opaque Token

An opaque token is a type of token used for authentication and authorization that does not contain any meaningful information in itself. Instead, it serves as a reference or identifier to a record stored on the server side, where the actual information and permissions associated with the token are stored.

In the context of OAuth authentication, an opaque token is typically issued by the authorization server and can be used by the client to access protected resources. Unlike JWTs, opaque tokens do not contain any claims directly within the token itself, making them less self-descriptive.

Please note that opaque tokens can be issued by providers other than OAuth, such as custom authentication systems or simply be a random string known by the client and the resource server.

Pros and Cons

Property	JWT	Opaque Token	API Token
Self-contained Contains all necessary information within the token itself, reducing the need for frequent database lookups.	✅	❌	❌
Stateless Contains all relevant information so that resource servers can validate and process them.	✅	❌	❌
Standard Format Standard format used making easy to parse and inspect, aiding debugging and troubleshooting.	✅ (JSON)	❔(Depends on the solution)	❌
Payload Size Larger token sizes can impact network overhead	❔ (JWT may be larger depending on the claims defined)	✅	✅
Informations exposure Do not contain readable information, reducing the risk of data exposure	❌	✅	✅
Server Load Do not require server-side validation for each request, potentially leading to increased server load and performance overhead.	✅	❌	❌
Token Lifetime (TTL) Expire after a certain amount of time so token leak has a limited impact duration.	✅	✅	❌

Decision Factors

Security

Here the main question is about the security of informations passed between the client and the resource server. JWTs expose the claims directly within the token itself, which can be read by anyone who has access to the token. This can be a security risk if sensitive information is included in the token. In contrast, opaque tokens do not expose any information directly, making them more secure in terms of data exposure.

In the context of Machine to Machine communications, where the client is acting on its own behalf, the risk of data exposure may be lower compared to user-based authentication scenarios. The JWT may not contains sensitive information between two machines.

Ease of implementation

JWT is a standard format that is widely used and supported by many libraries and frameworks. This makes it easier to implement and integrate with existing systems. Opaque tokens, on the other hand, may require custom implementations or additional logic to handle the token validation and processing.

Scalability

The self-contained nature of JWTs can be beneficial for scalability, as it reduces the need for frequent database lookups to validate the token. This can help improve performance and reduce server load, especially in high-traffic scenarios. Opaque tokens, on the other hand, may require server-side validation for each request, which can impact scalability and performance.

JWT may be bigger than opaque tokens, which can impact network overhead. However, the impact may be negligible in many cases, especially when considering the benefits of self-contained tokens.

Compliance

Depending on the regulatory requirements or industry standards, one type of token may be more suitable than the other. For example, if data privacy regulations require that sensitive information be protected, opaque tokens may be preferred to avoid exposing data directly within the token.

Once again, in the context of Machine to Machine communications, the risk of data exposure may be lower compared to user-based authentication scenarios. The choice between JWT and opaque tokens should be based on the specific requirements and constraints of the system.

Recommendation

As a general recommendation, JWTs are a good choice for Machine to Machine communications due to their self-contained nature and ease of implementation.

The question may be different with user-based authentication, where the risk of data exposure is higher and opaque tokens may be preferred depending on the situation.

But, if you do not have an OAuth provider, you can use opaque tokens as a simple solution. Opaque tokens can be generated by the client and validated by the resource server without the need for a centralized authorization server. This can be useful in scenarios where a lightweight authentication mechanism is needed, and the overhead of JWTs is not justified.