You are describing stateful authentication.

Nope. You don't even need to know you issued those tokens or their state. You don't ever assert a state or check it. You force its recompute via cache bust.

You don't need to know a token of jakelazaroff. You don't need to know its state. You don't even need to know if it exists.

You know that a token associated with jakelazaroff iphone if it exists will have a tag jakelazaroff-iphone because every token associated with <user> iphone will always have a tag <user>-iphone since you always tag a token of any <user> on an iphone with a tag <username>-iphone when you issue the token.

I don’t understand your explanation, but the words that you’re using (e.g. “purges”, “cache”) indicate that you’re describing a stateful system.

Imagine you’re writing your API on AWS Lambda, so memory and the file system are not shared between requests. A client presents your API with a token. Using no external resources (no database hits, no network requests, etc) how do you determine the veracity of that token?

Edit: I think I understand what you’re saying. Using a CDN that will let you “tag” resources and conditionally provide access based on whether HTTP headers match those tags, you issue tokens to clients and add or remove tags to give and revoke access. The CDN determines whether a given tag can access the resource, and your application doesn’t worry about authentication.

This is still stateful. The tags are the state!

> Using a CDN that will let you “tag” resources and conditionally provide access based on whether HTTP headers match those tags, you issue tokens to clients and add or remove tags to give and revoke access.

The tokens are the resource.

Your auth is what tags the tokens. Your auth is the only entity that is able to compute the tags that would match the criteria of the tokens to invalidate them.

Correct. I can assert a validity of the token without touching any database. Not only that, but the API does not even need to compute what it is. That's what makes it stateless.

It’s not stateless, you’re just trading a database for “tags”. This is exactly the same as if you just placed a stateful authentication service that checks a database in front of your API. How do you think the CDN works?

I guess the idea is that it's "stateless" in the sense that you don't have to maintain the state yourself, and the CDN will do it for you? I mean... okay, I guess the point of being stateless is that you don't want to deal with the scaling and reliability issues around storing state, so pushing that responsibility onto a third party (whose uptime is required to get to your site anyway) is "stateless" from your perspective.

I certainly wouldn't call that "stateless", but it does fulfill the main reason why you might want to be stateless, that you don't have to maintain any state yourself.

Exactly — it's basically the same as writing your own separate authentication service, or using Auth0/Cognito/Firebase.

The reason why it is stateless is because there's no state associated with a token that I have to maintain.

You do not maintain the tags. You compute the tags and you do not care what so ever if the tag ever matches anything.

It doesn’t matter who maintains them — the tags are still state. It may be stateless from your API’s perspective, but the system as a whole is still stateful.