Cookie-based vs Session vs Token-based vs Claims-based authentications

Question

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?

Answer 1

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.

Answer 2

Simply put,

1. Cookie-Based Authentication

   • Web-client (eg: web-browser) stores cookie sent by the web-server after successful authentication.
   • Cookie contains info about the user, client, authN timestamp and other useful data with unique-id to determine the cookie.
   • Typically, cookie is encrypted by the web-server with domain attribute set (eg: google.com) and send it across to the web-client.
   • Whenever the web-client wants to access the domain resource (eg: mail.google.com), it will send all cookie based on its domain (eg: google.com) to the web-server, which validates/ verifies and grant/ deny access based on state and timestamp of the cookie.

2. Session-Based Authentication

   • Along with the web-client cookie, if a web-server stores the user authN data in their back-end, then it will be called Session-based authentication.
   • This is very useful in the event of any breach that the web-client gained access to the system where it shouldn't get access, then from the back-end, the web-client's session can be revoked by the admin.

3. Token-Based Authentication

   • Generally this is used in non web-client scenarios, where there is no way to store cookie in the client side.
   • Hence, the web-server sends the signed token (contains info about user, client, authN timestamp and other useful data with unique-id) to the client after successful authentication.
   • Whenever, a client wants to access a resource, it need to send this token and web-server validates/ verifies the token before it allow to access the resource.

4. Claims-Based Authentication

   • This is same as token-based authentication, only that it add some more data into the token about the client and/or user associated to the client.
   • These data are pertain to authorization, which talks about what the client shall do within the resource (eg: mail.read, mail.delete, calendar.read).