4 ms·

Of course you can. Put your auth behind a sane CDN with TTL of forever, the kind that allows tagging an arbitrary number of objects with a single tag and allow

Of course you can. Put your auth behind a sane CDN with TTL of forever, the kind that allows tagging an arbitrary number of objects with a single tag and allow to purge objects matching a tag in a single call within a few milliseconds. Tag them with sec-uid, sec-uid-dev-id, sec-devclass, sec-we-dont-like-user etc to group them together. Want to kill sessions of just user uid? Hit a purge endpoint that purges all objects with sec-uid. Want to kill a session for a specific user for a specific device? Hit the purge endpoint that purges all objects with a tag sec-uid-sec-devid. Want to logout all users on an iPhone because "oops, security bug in a version we rolled out"? Hit an endpoint that purges all the docs tagged with sec-devclass of an iphone. You don't even need to remember tokens you issued.

jakelazaroff 7y ago
You are describing stateful authentication.
- notyourday 7y ago
  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.
  - deleted 7y ago
    [deleted]
  - jakelazaroff 7y ago
    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!
    - notyourday 7y ago
      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.
      - jakelazaroff 7y ago
        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?
        notyourday 7y ago
        You do not maintain the tags. You compute the tags and you do not care what so ever if the tag ever matches anything.
        jakelazaroff 7y ago
        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.
        kelnos 7y ago
        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.
        notyourday 7y ago

jakelazaroff 7y ago

You are describing stateful authentication.

notyourday 7y ago
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.
- deleted 7y ago
  [deleted]
- jakelazaroff 7y ago
  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!
  - notyourday 7y ago
    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.
    - jakelazaroff 7y ago
      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?
      - notyourday 7y ago
        You do not maintain the tags. You compute the tags and you do not care what so ever if the tag ever matches anything.
        jakelazaroff 7y ago
        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.
      - kelnos 7y ago
        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.
        notyourday 7y ago