How do you revoke an encrypted session token that doesn't need to hit the database to see if the request is authorized?

Include an expiry time in the encrypted part. The encryption, and the fact the token decrypts invalidly if not encrypted with the correct key, acts like a discount JWT.

Encrypted session tokens with embedded expiry will serve the needs of 99% of applications/services.

In that case why not use JWTs which do this for you? In your case you end up building a subset of JWTs yourself.

A subset of JWTs sounds great given the previous security vulnerabilities found in JWTs and the huge surface area they give you:

https://www.akto.io/blog/jwt-none-algorithm-test

This is not a huge surface area. I don't know why this keeps coming up, but, while a silly default, is incredibly straightforward to not configure / remove / test for.

JWTs are definitely a much larger surface area than simpler encrypted sessions storage and most people don’t need that.

I cited this as one example of that surface area that led to serious vulnerabilities. Most people don’t need multiple ways to encrypt their data, and certainly not a ‘no encryption’ option. Each added option adds more ways to mess things up.

These might predate JWTs.

Indeed, RFC 7519 dates from 2015 while both Rails and Django are older than that by a decade or more.

JWTs are complex.

Encrypted session cookies are a proven solution, widely used, and easy to implement yourself using only core libraries (http, crypto, JSON) without introducing security flaws IFF you are an experienced programmer and don’t deviate from the norm.

JWTs are complex. Too complex to implement yourself, so you need to introduce dependencies. Dependencies are usually huge, and each line of code introduces risk (even if that line is for a configuration you don’t use!). Using JWTs at all is far more risky, even if you are an experienced programmer.

If JWTs provides immense benefits over session tokens for your use case, that risk might be worth it. However, for most web apps, session tokens are good enough.

No idea why you're being downvoted. This is the truth.

Revocation in this context almost always means "suspension of the validity of a token prior to expiration", so that's not really an answer.

Sure. Just pushing back on the ‘you’re going to hit the database anyway’ argument. Having some kind of mechanism for eliminating obviously bogus requests is a good idea. Some sort of signed, expiring token is probably a good idea for that. Rolling your own expiry/signing mechanism is probably a bad idea. Correctly validated JWTs are an option (among many) for solving that problem.