The Biscuit Approach: Reinventing Authorization Tokens

In the world of authentication and authorization, JWTs (JSON Web Tokens) have become a popular choice for many developers. They offer a stateless mechanism, allowing for easy and efficient authentication. However, one pain point that continues to plague JWTs is the issue of revocation. Once a JWT is issued, it is difficult to revoke access without maintaining some form of state. This is where Biscuit, a new authorization token approach, comes into play.

Revocation Woes of JWTs

JWTs are great for many use cases. They allow for quick authorization without the need for a database query. However, in situations where revocation is necessary, JWTs fall short. Revocation requires maintaining a revocation list, which defeats the purpose of stateless bearer tokens. As one user put it, “Revocation is essentially the Achilles heel of JWTs.”

Introducing Biscuit: A Fresh Take on Authorization Tokens

Biscuit, an alternative to JWTs, aims to address the revocation challenge while offering additional benefits. According to the author of Biscuit, revocation can be managed through a system of “revocation IDs.” Each token block is assigned a unique revocation ID. By adding the revocation ID of the last block to the revocation list, all tokens derived from that one can be revoked. However, it is important to note that, as with any bearer token system, revocation reintroduces some degree of state.

While some may question the need for Biscuit over JWTs, there are advantages that make it worth considering. Biscuit specifies its own authorization language, allowing for more flexible and granular checks to be carried out by the token itself. It also offers attenuation, which enables a user to give someone else a weaker form of their authorization. In addition, Biscuit introduces third-party blocks, expanding the possibilities for token usage.

The Role of Authorization Language

One commenter questioned the need for an authorization language within the token itself, suggesting that developers can implement authorization logic within their application. However, Biscuit’s authorization language serves a purpose, especially in scenarios where a user with certain authorization wants to grant someone else a limited version of that authorization. Biscuit’s flexibility allows for more sophisticated delegation and fine-grained access control.

The Trade-Offs and Considerations

It is important to acknowledge that there is no perfect solution when it comes to authorization tokens. JWTs have their advantages in certain scenarios, such as avoiding unnecessary database queries and reducing attack surface. On the other hand, Biscuit offers a different approach with its revocation implementation and additional features like attenuation and third-party blocks.

One user pointed out that every solution for revocation involves maintaining some form of token list, whether it is a blacklist or a whitelist. Both approaches have their trade-offs and limitations. Each organization must evaluate their specific requirements and threat model to determine the best approach for their system.

While Biscuit may not be the solution for every use case, it aims to provide an alternative for those who require a more nuanced authorization mechanism. It offers a way to handle revocation while providing a flexible authorization language and additional features that JWTs may not offer out of the box.

In the end, the choice between JWTs and Biscuit depends on various factors, such as the specific requirements of the application, the desired level of authorization granularity, and the trade-offs an organization is willing to make. Regardless of the chosen approach, it is crucial to carefully evaluate the security implications and consider the best practices for handling authentication and authorization.