Token Authentication vs. Cookies

Question

What is the difference between token authentication and authentication using cookies?

I am trying to implement the Ember Auth Rails Demo but I do not understand the

Answer 1

• Tokens need to be stored somewhere (local/session storage or cookies)

• Tokens can expire like cookies, but you have more control

• Local/session storage won't work across domains, use a marker cookie

• Preflight requests will be sent on each CORS request

• When you need to stream something, use the token to get a signed request

• It's easier to deal with XSS than XSRF

• The token gets sent on every request, watch out its size

• If you store confidential info, encrypt the token

• JSON Web Tokens can be used in OAuth

• Tokens are not silver bullets, think about your authorization use cases carefully

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Answer 2

Use Token when...

Federation is desired. For example, you want to use one provider (Token Dispensor) as the token issuer, and then use your api server as the token validator. An app can authenticate to Token Dispensor, receive a token, and then present that token to your api server to be verified. (Same works with Google Sign-In. Or Paypal. Or Salesforce.com. etc)

Asynchrony is required. For example, you want the client to send in a request, and then store that request somewhere, to be acted on by a separate system "later". That separate system will not have a synchronous connection to the client, and it may not have a direct connection to a central token dispensary. a JWT can be read by the asynchronous processing system to determine whether the work item can and should be fulfilled at that later time. This is, in a way, related to the Federation idea above. Be careful here, though: JWT expire. If the queue holding the work item does not get processed within the lifetime of the JWT, then the claims should no longer be trusted.

Cient Signed request is required. Here, request is signed by client using his private key and server would validate using already registered public key of the client.

Answer 3

Token based authentication is stateless, server need not store user information in the session. This gives ability to scale application without worrying where the user has logged in. There is web Server Framework affinity for cookie based while that is not an issue with token based. So the same token can be used for fetching a secure resource from a domain other than the one we are logged in which avoids another uid/pwd authentication.

Very good article here:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

Answer 4

For Googlers:

• DO NOT mix statefulness with state transfer mechanisms

STATEFULNESS

• Stateful = save authorization info on server side, this is the traditional way
• Stateless = save authorization info on client side, along with a signature to ensure integrity

MECHANISMS

• Cookie = a special header with special treatment (access, storage, expiration, security, auto-transfer) by browsers
• Custom Headers = e.g. Authorization, are just headers without any special treatment, client has to manage all aspects of the transfer
• Other. Other transfer mechanisms may be utilized, e.g. query string was a choice to transfer auth ID for a while but was abandoned for its insecurity

STATEFULNESS COMPARISON

• "Stateful authorization" means the server stores and maintains user authorization info on server, making authorizations part of the application state
• This means client only need to keep an "auth ID" and the server can read auth detail from its database
• This implies that server keeps a pool of active auths (users that are logged in) and will query this info for every request
• "Stateless authorization" means the server does not store and maintain user auth info, it simply does not know which users are signed in, and rely on the client to produce auth info
• Client will store complete auth info like who you are (user ID), and possibly permissions, expiration time, etc., this is more than just auth ID, so it is given a new name token
• Obviously client cannot be trusted, so auth data is stored along with a signature generated from hash(data + secret key), where secret key is only known to server, so the integrity of token data can be verified
• Note that token mechanism merely ensures integrity, but not confidentiality, client has to implement that
• This also means for every request client has to submit a complete token, which incurs extra bandwidth

MECHANISM COMPARISON

• "Cookie" is just a header, but with some preloaded operations on browsers
• Cookie can be set by server and auto-saved by client, and will auto-send for same domain
• Cookie can be marked as httpOnly thus prevent client JavaScript access
• Preloaded operations may not be available on platforms other than browsers (e.g. mobile), which may lead to extra efforts
• "Custom headers" are just custom headers without preloaded operations
• Client is responsible to receive, store, secure, submit and update the custom header section for each requests, this may help prevent some simple malicious URL embedding

SUM-UP

• There is no magic, auth state has to be stored somewhere, either at server or client
• You may implement stateful/stateless with either cookie or other custom headers
• When people talk about those things their default mindset is mostly: stateless = token + custom header, stateful = auth ID + cookie; these are NOT the only possible options
• They have pros and cons, but even for encrypted tokens you should not store sensitive info

Link

Answer 5

I believe that there is some confusion here. The significant difference between cookie based authentication and what is now possible with HTML5 Web Storage is that browsers are built to send cookie data whenever they are requesting resources from the domain that set them. You can't prevent that without turning off cookies. Browsers do not send data from Web Storage unless code in the page sends it. And pages can only access data that they stored, not data stored by other pages.

So, a user worried about the way that their cookie data might be used by Google or Facebook might turn off cookies. But, they have less reason to turn off Web Storage (until the advertisers figure a way to use that as well).

So, that's the difference between cookie based and token based, the latter uses Web Storage.

Answer 6

One of the primary differences is that cookies are subject to Same Origin Policy whereas tokens are not. This creates all kinds of down stream effects.

Since cookies are only sent to and from a particular host that host must bear the burden of authenticating the user and the user must create an account with security data with that host in order to be verifiable.

Tokens on the other hand are issued and are not subject to same origin policy. The issuer can be literally anybody and it is up to the host to decide which issuers to trust. An issuer like Google and Facebook is typically well trusted so a host can shift the burden of authenticating the user (including storing all user security data) to another party and the user can consolidate their personal data under a specific issuer and not have to remember a bunch of different passwords for each host they interact with.

This allows for single sign on scenarios that reduce overall friction in the user experience. In theory the web also becomes more secure as specialised identity providers emerge to provide auth services instead of having every ma and pa website spinning up their own, likely half baked, auth systems. And as these providers emerge the cost of providing secure web resources for even very basic resources trends towards zero.

So in general tokens reduce the friction and costs associated with providing authentication and shifts the burden of the various aspects of a secure web to centralised parties better able to both implement and maintain security systems.