3 ms·

I feel that this table leads readers into thinking that the top axis is a set of things you need to choose between, but many of them are orthogonal. JWTs, for e

I feel that this table leads readers into thinking that the top axis is a set of things you need to choose between, but many of them are orthogonal. JWTs, for example, can be used as a particular (standardized) "stateless session cookie" if you store them as a cookie. They do not, contrary to what the table says, need to be stored in local/session storage, though that is an option. Similarly with "Random Token" and "Stateful Session Cookie". OAuth, similarly, is orthogonal to the rest of the table. You can easily use JWT as your token format in OAuth. The key decisions you have to make are something like, * Do I have any sort of "authentication token", or does the client simply auth each request? If you go w/ authing each request, you get things like HTTP Basic Auth, or AWS's style. If you go with some sort of token, then you get both of the following questions: * If token, do you store the token in a cookie, or local/sessionStorage? (The former is vulnerable to CSRF, the latter can be read by JS in an XSS.) * If token, what kind of token? A reference to a row in a DB, or do you just give the client a signed and possibly encrypted blob detailing the authentication? If you go w/ a signed and possibly authenticated blob, then JWT provides a standard format for representing that data and many of the concerns around authentication tokens, such as expiration. I'm probably over-simplifying a bit. The table just doesn't — for me — do a good job of showing the various choices along the spectrum, and what consequences arise from which choices. (Aside from also conflating JWTs with where you store an auth token, and Oauth with auth tokens) ("Stateless Session Cookie" is a bit of an oxymoron.)

ksri 10y ago
Author here. The spreadsheet started off with a brain dump, and then was revised into this blog post - https://hashedin.com/2016/07/05/choosing-right-authentication-for-rest-apis/ https://hashedin.com/2016/07/05/choosing-right-authenticatio.... Perhaps this is more in line with what you have laid down?
- deathanatos 10y ago
  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.) [1]: https://security.stackexchange.com/questions/81756/session-authentication-vs-token-authentication https://security.stackexchange.com/questions/81756/session-a...

ksri 10y ago

Author here. The spreadsheet started off with a brain dump, and then was revised into this blog post - https://hashedin.com/2016/07/05/choosing-right-authentication-for-rest-apis/ https://hashedin.com/2016/07/05/choosing-right-authenticatio.... Perhaps this is more in line with what you have laid down?

deathanatos 10y ago
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.) [1]: https://security.stackexchange.com/questions/81756/session-authentication-vs-token-authentication https://security.stackexchange.com/questions/81756/session-a...