The overall structure, yes, I think is much clearer than a spreadsheet. The specifics leave me with a lot of questions though:
What do you define "session" and "token" based authentication as? My best guess is that "session" means an opaque identifier that identifies the authentication details stored server side, and "token" means a complete structure that details the authentication, but to me, those are odd words to associate with those things. Nonetheless, Googling that seems to indicate that you're not the first to use these terms this way, and that this might be accepted terminology for these concepts that I've just missed entirely (hopefully I've gotten the right impression from resources like [1]). I'm not sure I'm fond of those words for those concepts, if that is indeed what you mean, since they don't seem to provide real clues as to the thing they describe. (Why is an opaque DB ID not a token?) That said, I've not got a discrete word for these concepts.
> If no, or if you don’t know what CSRF is – prefer token based authentication.
But token based authentication — if you do mean a signed blob of authentication details, such as JWT — is no more inherently immune to CSRF than an opaque "session" ID into a database somewhere. Either can be stored in a cookie, and vulnerable to CSRF, and either can be stored in localStorage and thus immune to it. How you structure your authentication credential (JWT or a opaque DB ID) is orthogonal to how you store/transmit it on the client.
> You should use JWT as a short, one-time token, and not as something that is reused multiple times.
Why? Does that not completely defeat the point of a JWT? I suppose you could do this, and I suppose it would work, but that would require the client to reauthenticate each individual request, and that's more overhead than most people are willing to bear, and I don't feel that's really how most people use a JWT. (I would say most people have an authentication server or endpoint issue a JWT for a reasonable set of audiences for a reasonable length of time, and then use that JWT over multiple API calls.)
> Instead of JWT, create a random token, store it in redis/memcached, and validate it on every request.
Again, one of the great points of a JWT is that you can validate it with little to no network traffic.
> Session based mechanisms are painful because a mobile app doesn’t automatically maintain and send the session cookie. For a mobile app developer, it is far easier to set an authentication token as opposed to setting a session cookie.
Again, here, I feel like we're mixing up whether we're using an signed-authentication-structure "token" or an opaque "session" ID w/ how it's transmitted (via the Cookie header, or via the Authentication header). While I'd personally prefer Authentication simply because the structure and function of that header is simpler. But, why is it easier for the mobile developer to set one header over the other, really?
> Signature based mechanisms are generally not useful because you cannot embed secret keys in a mobile application.
We're talking about presumably authenticating the user of the mobile app — why would his or her credentials be embedded in the application at all? (If you mean a signature based auth like what AWS uses, the AWS id/secret would presumably be stored very similarly to however a mobile app would store my username/pass, or a JWT, or a session token; the issue is the device's storage mechanisms, not the authentication protocol. I'm not saying you should store an AWS key in an app, I'm merely detailing that type of flow, e.g., an HMAC of the actual request details.)
> If yes, prefer token based authentication, because signature based auth requires clients to store secrets.
A JWT token is a secret. A username and password is a secret. A DB identifier for a session is a secret. Any of those, if divulged, result in the ability to make authenticated requests.
> OAuth 2 uses token based authentication.
This doesn't jive with the definitions of session/token auth that I've been using at all, so I'm lost. OAuth2 works with either.
> Server-to-server API calls, where the client can store a shared secret and generate a new JWT for each API call.
This statement is so unusual to me that I want to know how you think JWT works. If the client can create JWTs, why use it at all, as opposed to the much simpler basic auth, or AWS-like signature-based authentication?
For reference, to me, a JWT is a standardized structure that describes the assertion that a particular subject (typically a user) is authenticated, potentially for a limited set of things, typically for a limited amount of time (it expires). It's proof that the user authenticated in some manner. Typically,
1. a client would authenticate w/ an authentication server (potentially, the same server it'll later make API calls to, particularly for small services, but not necessarily); if successful, the server returns a JWT, good for some period of time. (This step could be OAuth, the access token could be a JWT, but does not need to be.)
2. a client proceeds to make API calls using that JWT, supplying it in some manner, perhaps as an Authentication header, perhaps as a cookie. (of course, the server/client must agree on the method)
3. the receiving server can prove that the client is authenticated from the information in the JWT alone, since it's a signed message from the authentication server claiming that. (Excepting some things about revocation of JWTs.)
(I'm not saying this is the only way to use JWTs, just the way I would expect most web applications to make use of them.)
