JSON Web Token (JWT) is a standard way to represent authenticated claims transferred between two parties.
Typical JWT issuer is a server communicating with a client, who is the claims subject. JWTs are in order to offload state management related to authentication and authorization. Once issued, a JWT can be used by a subject a number of times for authentication with the issuer or third parties. Typically, a JWT is transferred from the client as a bearer token, that is, within the Authorization header of the HTTP request.
The party receiving a JWT can verify it independently and without maintaining a persistent session with the client (which is how authentication generally worked in schemes proposed earlier, e.g., ones based on cookies). In other words, JWT-based authentication is stateless.
JWTs rely on cryptographic primitives – encryption or digital signatures – to ensure claim integrity, i.e., the fact that claims provided within a JWT have not been tampered with and come from a trusted issuer. As such, JWT is an extension of other standards: JSON Web Signature (JWS) and JSON Web Encryption (JWE).
Tokens based on asymmetric signature algorithms, such as RSA or EdDSA, allow independent verification since information necessary to verify token integrity (a verifying key) is non-secret and does not compromise information necessary to issue a token (a signing key). Even if verifier is logically the same as the token issuer, it can be split off in terms of systems, thus reducing centralization and risk of secret leakage. Hence, JWS-powered JWTs are more common and are sometimes called just “JWTs,” without the “JWS” qualifier.
Want to see JWTs in action?
Alternatives
There are several technologies providing functionality similar to that of JWTs, although use cases they cover differ from ones where JWTs are typically employed.
Macaroons
Macaroons are authorization credentials cryptographically protected with hash-based message authentication codes (HMACs). Most notably, the subject can pass a macaroon to a third party narrowing down the list of its credentials with the help of caveats (e.g., go from “read all resources of a certain type” to “read the resource with a specific ID”); such a macaroon will still be cryptographically protected.
In contrast to JWTs, information in macaroons is narrowly focused on authorization claims (i.e., “the subject can do X” instead of “the subject is X”). Partially because of relatively complicated use cases for caveats, macaroons are less popular compared to JWTs.
Verifiable credentials
Verifiable credentials (VCs) is a relatively recent Web standard for representing, issuing and verifying claims. Compared to JWTs, VCs are much more focused on third-party, universal verification (JWTs are mostly verified by the issuer at least from the organizational perspective). Accordingly, VC holder is an active party making a conscious decision which VCs to provide for verification and to whom, while in JWT case this is usually fully automated by client-side scripting.
Because of the technology recency, VCs are less supported compared to JWTs. Complicating this matter, VCs may employ more complex cryptography, such as attribute-based credentials, in order to overcome limitations imposed by simpler JWT crypto. For example, linking usage of a single JWT is trivial (the JWT is provided in plaintext for each usage), while VC constructions may specifically design for non-linkable usage.