Authentication Methods – Cookie-based vs Session vs Token-based vs Claims-based

authentication

I have read about authentications and become confusing about types classification.

Let's start from Cookie-based authentication, If I understand it right, the key point is that all data, needed for user authentication, is stored in cookies. And this is my first confusion: in cookies we may store

  • session id and so it becomes a Session-based authentication?
  • claims, and so should it be called as a Claims-based authentication?
  • I have found that some people even store JWT token in cookies, but this seems like a custom implementation of own auth flow…

Now let's switch to Claims-based authentication. The main element is the claim and the collection of claims could use as container

  • cookies (as discussed above)
  • token (JWT as the example).

From the other side, when we are talking about the token, it may contain any kind of information… Session Id for example…

So what have I missed? Why don't people define something like Cookie-Session-based or Token-Claims-based authentications when talking about authentication types?

Best Answer

I agree that the naming of the different concepts is confusing. When talking about authentication in a web context, there are several aspects to consider.

What information does the client send when authenticating?

  • A session id. This means that the server has a session storage which contains the active sessions. Sessions are stateful on the server side.
  • A set of claims. Claims contain information on what operations the client may perform. The server does not keep track of each authenticated client, but trusts the claims. Claims are typically stateless on the server side.

How does the client send the authentication information?

  • Cookies. Browsers send cookies automatically with each request, after the cookie has been set. Cookies are vulnerable to XSRF.
  • Other headers. Typically, the Authorization header is used for this. These headers are not send by the browser automatically, but have to be set by the client. This is vulnerable to XSS.
  • Request Url. The authentication information is included in the URL. This is not commonly used.

What is the format of the authentication information?

  • Plain, unsigned text. This can be used for session ids. A session id is generally not guessable by the client, so the server can trust that the client has not forged it.
  • Json Web Token. JWTs are cryptographically signed and contain expiry information. The client can usually decode the token, but cannot alter it without the server noticing.
  • Any other signed format. Same as JWTs. The important thing is the cryptographic signature, which prevents the client from altering the data.

Bonus: How does the client store the information locally

  • Cookies. This is of course the case when using cookies to transmit the information. But Cookies can also be used as just a client side storage mechanism. This requires the cookie to be readable from scripts to be useful. For example, a client could read the cookie with JavaScript and send the information with an Authorization-Header.
  • Local Storage. This is often the only possible method, if cookies are unavailable. Requires management with JavaScript.

What do people mean when they say...

  • "Cookie based authentication". I find that this usually means "Session id, send by cookie, possible as plain text."
  • "Token based authentication". Usually this means "Claims, send using the authentication header, encoded as a Json Web Token."
  • "Claims based authentication". Could be anything but a session id.
Related Topic