Not impressed, particularly with the basic-auth description. Basic auth is purely a well understood vehicle for sending a tuple (aka the credentials) for authenticating a HTTP request, most of the concerns highlighted are with regards to how the credentials are acquired and potentially reused across requests - that has nothing to do with the HTTP protocol.
For example, my API product scanii.com has used basic auth for 7+ years and I firmly believe it strikes the right balance between security and easy of use. Besides fairly complex key/secret tuples for server side usage, we also provide one-time auth tokens for when you want to make API calls directly from a web browser (or another insecure device).
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".<p>OAuth, similarly, is orthogonal to the rest of the table. You can easily use JWT as your token format in OAuth.<p>The key decisions you have to make are something like,<p>* Do I have any sort of "authentication token", or does the client simply auth each request?<p>If you go w/ authing each request, you get things like HTTP Basic Auth, or AWS's style.<p>If you go with some sort of token, then you get <i>both</i> of the following questions:<p>* 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.)<p>* 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?<p>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.<p>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)<p>("Stateless Session Cookie" is a bit of an oxymoron.)
Who is the author? It's just a bare Google Doc AFAICT.<p>Some quick notes: random tokens do rely, broadly speaking, on cryptography, as the token must be generated by a cryptographically strong (P)RNG.<p>Signing and encryption are conceptually different ideas, don't mix them as in the description of the stateless session cookie. There's a great old Matasano blog post in the style of a play about this...<p>A more complete consideration of authn techniques would include mutual certificate ("SSL") authn, as well as signed-request approaches not using a shared secret.
Every time I see "API" and "authentication" I go look to see whether they have incorporated the best practice of always be willing to accept two different authentication credentials/passwords/etc. So that upgrades can happen where first one side will accept a new password, then the other side switches what it sent, then the old password is discontinued.<p>Rather than the common "big bang" upgrade where everything has to update at once. (A process which is so scary that in fact it turns into passwords NEVER getting updated.)<p>Yeah, sadly this idea is never mentioned. :-(
I seriously don't understand the hype around JWT. They're useless to me since they can't be revoked. It's so much easier to just use a secure random token with an expiry. I could understand JWT at-scale to avoid hits to the DB, but none of us are likely at that scale.
Calling the last column "OAuth" over-simplifies quite a bit. Specifically, there are ways to do OAuth like client credentials that don't involve 3 parties. OAuth provides a standard way of solving authentication, and it makes life easier for developers. Saying it's "overkill" might turn people away from a solution that could help them get and retain API customers.
More about client credentials here:
<a href="https://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-4.4" rel="nofollow">https://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-4...</a>
JWT docs aren't accurate. Also why not just store JWT in the cookie? It's pretty trivial to use JWT in a cookie and do a sliding refresh on server side when its close to expiring. You can use JWT this way with zero code on the client.<p>Same with the "Random Token". You can easily just shove a secure random ID in a session cookie and use it. Doesn't pretty much every framework support this?<p>This docs is... not accurate for most of these.
Keeping this information, which I think is very useful, on a github repo here: <a href="https://github.com/teamsecure/authentication" rel="nofollow">https://github.com/teamsecure/authentication</a>. Submit PR or create issue and collaborate if you feel like to do it :)
Question about this from your blog:<p>> Does your web framework protect against CSRF? If no, or if you don’t know what CSRF is – prefer token based authentication.<p>Can you elaborate on this? If I implement CORS and also make sure my API is well-designed (for example, GET requests are truly idempotent and do not mutate anything), am I not protected from CSRF?<p>Thanks!