Encrypted instead of signed access tokens in OAuth2

Question

In OAuth2 access token is typically JWT signed by authorization server. Assuming that we will use Ed25519 to sign the JWT, we will have 128 bits of security.

But what about access tokens that would be encrypted with XChaCha20-Poly1305 instead of using signing? We will have 256 bits of security and access tokens will be opaque to the client (so also to attackers). In this scenario, even if access token is stolen (and we don't use something like DPoP or certificate-constrained tokens) then attacker doesnt have knowledge where to use this access token.

Resource servers will be forced to use introspection endpoint, but whole idea seems pretty good to me. Do you see any security issues or other disadvantages?

Answer 1

OK, first of all, the opaqueness is irrelevant. There's basically no situation where somebody is going to be able to steal an access token without knowing where it's intended for use, nor any situation where the token's use won't immediately reveal who it was issued to (if the attacker even cares).

Second, you're comparing asymmetric and symmetric crypto. If you care about the difference between 128-bit security and 256-bit security... first of all, your threat model probably makes no sense unless you're expecting practical quantum computers to make a tremendous breakthrough and hit commercial viability, but second of all, just use HMAC-SHA[2|3]-512. Faster, simpler, at least as secure, standardized so you don't have to roll your own cryptosystem about it.

Third, you aren't even increasing the security! In fact, you're probably decreasing it. The authentication tag is only 128 bits long, and - at least according to https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ - probably only provides about 100 bits of entropy protecting against forged messages. Which is probably OK for the mid-term future, to be clear, but the protection offered by the auth tag is the only bit you actually care about here, so it's pretty sad for that protection to actually go down because you switched to your own construction for more security.

Answer 2

Why not use JSON Web Encryption (JWE) then? The token is encrypted by a symmetric Content Encryption Key (CEK) and CEK is exchanged by key agreement. You have to consult with your OIDC provider's documentation for key agreement protocol that they support.

Token introspection should be used when it becomes a necessity. For example, if you have legacy services that either do not support JWT or use static API keys, they can make use of token introspection to verify opaque access tokens issued by the OIDC provider. JWT access tokens can be verified in memory. Encrypting them and sending them for introspection is an avoidable overhead for your service. Also, encrypting access tokens does not mitigate the risk of stolen access tokens. If the attacker is in a position of stealing access tokens from the user or from your services, he knows how and where to use them. The attacker will just use encrypted access token as is which will pass token introspection.