Authentication Techniques for APIs
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) &quot;stateless session cookie&quot; if you store them as a cookie. They do not, contrary to what the table says, need to be stored in local&#x2F;session storage, though that is an option. Similarly with &quot;Random Token&quot; and &quot;Stateful Session Cookie&quot;.<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 &quot;authentication token&quot;, or does the client simply auth each request?<p>If you go w&#x2F; authing each request, you get things like HTTP Basic Auth, or AWS&#x27;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&#x2F;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&#x2F; 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&#x27;m probably over-simplifying a bit. The table just doesn&#x27;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>(&quot;Stateless Session Cookie&quot; is a bit of an oxymoron.)