Why mobile apps are usually authenticated via token, not cookies

Question

I am currently planning infrastructure for the new project with common backend for web and mobile application. The mobile applications are usually authorised by tokens, not the cookies but I am wondering why? I have few ideas in mind like lack of flexibility in setting and prelonging cookies based authentication, but I want to know the real argument behind tokens.

Answer 1

I have some experience with JSON web tokens. So I write about those.

Reason 1:

One concern is application scalability. When you use a cookie it normally goes like this:

1. User logs in. Cookie is issued with the session ID in it. The session ID is persisted in a shared session store in the backend. Cookie is stored in browser.
2. Cookie is presented at each request. The backend takes the session ID from the cookie and checks in some sort of database if the session ID is known.

So basically you have this overhead of looking up the session ID on every request. Now, this means that all backend servers have to know of the session ID - they share some sort of resource to look up the session ID. The alternative is to come up with some clever request routing, so that each user hits a fixed server where she was authenticated on. So I can't easily introduce a new server.

On the other hand a token like a JSON web token is just a crytographically secured claim, that one was authenticated (and maybe additional claims about the user). It goes like this:

1. User logs in. Token is issued that proves that claims that the user was authenticated (+ optional user info). The token is cryptographically signed by the issuer.
2. The token is presented at each request. As it is signed, we can detect if the token is valid and unaltered. Also we can say who has issued the token.

Now, as each server can cryptographically prove that the token was issued by a trusted party (in most cases on of our backend servers), the backend server is sure that the user was authenticated. However, you don't need that shared session storage anymore. So, e.g. it does not matter at all which server a request goes to. This enhances scalability and makes ops a little bit easier.

Reason 2: A cookie is limited in size to 4KB. A token is not limited in size, so it can transport more information (of course a token should be small nevertheless).

Reason 3: Theoretically, you can control in your web app when to send the token. It's not necessary for anyonymous resources. A cookie is sent with each request.

Reason 4: A cookie is issued for one domain. If you access another domain, then you are in trouble. A token on the other hand can be sent to any domain.

Drawback 1: There's no free lunch, however. A cookie can be protected by the HttpOnly flag, so that it can't be accessed in Javascript. That makes XSS hard(er). On the other hand this is not possible with tokens.