What is token-based authentication?

Question

I want to understand what token-based authentication means. I searched the internet but couldn't find anything understandable.

Frankfurter

I have read a lot of descriptions, but they all seemed light on concrete details. This article finally helped me: scotch.io/tutorials/the-anatomy-of-a-json-web-token – Blindly

A linked blog to the one suggested by @ChrisConover - How JSON web tokens came into existence? – Unpolitic

simplest explaination can be found here.link – Quinton

Answer 1

I think it's well explained here -- quoting just the key sentences of the long article:

The general concept behind a token-based authentication system is simple. Allow users to enter their username and password in order to obtain a token which allows them to fetch a specific resource - without using their username and password. Once their token has been obtained, the user can offer the token - which offers access to a specific resource for a time period - to the remote site.

In other words: add one level of indirection for authentication -- instead of having to authenticate with username and password for each protected resource, the user authenticates that way once (within a session of limited duration), obtains a time-limited token in return, and uses that token for further authentication during the session.

Advantages are many -- e.g., the user could pass the token, once they've obtained it, on to some other automated system which they're willing to trust for a limited time and a limited set of resources, but would not be willing to trust with their username and password (i.e., with every resource they're allowed to access, forevermore or at least until they change their password).

If anything is still unclear, please edit your question to clarify WHAT isn't 100% clear to you, and I'm sure we can help you further.

Trunk

Am I correct in thinking that in a web application, one (or more) cookies from the remote web site performs the function of the token? – Haydeehayden

From the W3 article you referenced: "Typical web-authentication is cookie-based..." – Haydeehayden

@Alex Martelli hi if connection is over HTTPS does that make a difference to send token as parameter or in header? – Lipman

As tokens are stored as cookies, is there anything in place to stop a person stealing that cookie/token and using it themselves, tricking the server into thinking they are the authorized user? Obviously they could only use it for x amount of time, but during that period they could do all the damage they needed to. – Castalia

@Chibbles You can use anti-forgery tokens for that. Also you could make sure the connection is encrypted with https. – Geny

@Rondles For this you secure your ressource with SSL which prevents the man in the middle from stealing your token. And if he steals your token you can still encrypt your token. – Meuser

@Lipman No, it makes no difference. In http(s), the requested resource, including the path and query string (i.e. parameters), and the headers are all sent as data, so both are therefore encrypted. – Avernus

How is this different from SessionAuthentication, where user can obtain a session_id by enterting his username and password, and then uses this session_id in subsequent request ? – Nickels

@AlexMartelli Let's say I'm using JWT as my token. Where do I store the token on browser side and do I need to manually send it back to server with each subsequent request or does the browser automate that somehow? I'm also having trouble understanding how it only provides limited access to resources. Please explain further. – Pelops

@user137717, your response's Set-Cookie: name=value (&c) header instructs the browser to store the cookie (no idea what you mean by "using JWT as my token") and the browser sends it back in requests to the same domain as the Cookie header. (You can take control w/Javascript if you're writing a client-side app to run in the browser, of course). The limits on the access granted (both in time and scope) are up to your server code to enforce. – Trunk

if the token expires does the user have to log in again to get a new token? – Fireplace

@AnthonyTo, depends on the token auth system -- you could get a "persistent token" that you're able to "refresh", or not, depending on the system! – Trunk

You don't need to store the token in a cookie. You can store it in local storage. – Bermuda

@SaurabhVerma it's different from a session because you don't have to store the information in a cookie. That is great for mobile devices, some of which have restrictions on cookie usage. – Ladylike

The problem with cookies is that the user must have them enabled, otherwise your authentication would not work. I'd recommend sending the token via the Authorization header to work around this fact. Also, it fits nicely to REST services, which are supposed to be stateless and may be hosted in a different domain. – Taxation

As a note : the fact that tokens are only valid for a limited time is an important distinction with sessions. When a token is intercepted it can only be abused for a limited time. – Artiodactyl

@Ladylike so a token stored in a cookie is equivalent to a session? We can say that session based authentication relis on token based authentication? – Netherlands

@AlexMartelli I know this is an old question. But I am still quite confused with token vs cookie can you take a look at my question #77444665 ? Thanks! – Austro

Answer 2

From Auth0.com

Token-Based Authentication, relies on a signed token that is sent to the server on each request.

What are the benefits of using a token-based approach?

• Cross-domain / CORS: cookies + CORS don't play well across different domains. A token-based approach allows you to make AJAX calls to any server, on any domain because you use an HTTP header to transmit the user information.

• Stateless (a.k.a. Server side scalability): there is no need to keep a session store, the token is a self-contained entity that conveys all the user information. The rest of the state lives in cookies or local storage on the client side.

• CDN: you can serve all the assets of your app from a CDN (e.g. javascript, HTML, images, etc.), and your server side is just the API.

• Decoupling: you are not tied to any particular authentication scheme. The token might be generated anywhere, hence your API can be called from anywhere with a single way of authenticating those calls.

• Mobile ready: when you start working on a native platform (iOS, Android, Windows 8, etc.) cookies are not ideal when consuming a token-based approach simplifies this a lot.

• CSRF: since you are not relying on cookies, you don't need to protect against cross site requests (e.g. it would not be possible to sib your site, generate a POST request and re-use the existing authentication cookie because there will be none).

• Performance: we are not presenting any hard perf benchmarks here, but a network roundtrip (e.g. finding a session on database) is likely to take more time than calculating an HMACSHA256 to validate a token and parsing its contents.

Jeopardous

@Jeopardous All points here are valid except "Stateless" when you start dealing with token revocation, blacklisting, reply attack prevention etc. – Uppercut

The cited site recommends a newer article on the same topic: auth0.com/blog/cookies-vs-tokens-definitive-guide – Goraud

'statelessness' and 'performance' holds as longs as you don't need to 'immediately' revoke the token. Otherwise at-least one db access per api call is necessary. – Undis

You might want to read "Stop using JWT for sessions": cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions – Intine

Link is now broken. – Forfeit

Access token is token, and it is not stateless. – Hazeghi

Answer 3

A token is a piece of data which only Server X could possibly have created, and which contains enough data to identify a particular user.

You might present your login information and ask Server X for a token; and then you might present your token and ask Server X to perform some user-specific action.

Tokens are created using various combinations of various techniques from the field of cryptography as well as with input from the wider field of security research. If you decide to go and create your own token system, you had best be really smart.

Swink

Generally, if you want token-based authentication, you should start with OAuth. – Dextrad

OAuth is certainly viable in a Web-based application. But, for example, operating system login sessions use token systems as well, as do many other kinds of software program, so this idea is not limited to the Web. – Swink

A token is probably also preferable for a non-public customer support system. The company controls the username/password and issues & controls the token. – Chuckle

Answer 4

A token is a piece of data created by server, and contains information to identify a particular user and token validity. The token will contain the user's information, as well as a special token code that user can pass to the server with every method that supports authentication, instead of passing a username and password directly.

Token-based authentication is a security technique that authenticates the users who attempt to log in to a server, a network, or some other secure system, using a security token provided by the server.

An authentication is successful if a user can prove to a server that he or she is a valid user by passing a security token. The service validates the security token and processes the user request.

After the token is validated by the service, it is used to establish security context for the client, so the service can make authorization decisions or audit activity for successive user requests.

Source (Web Archive)

Blackleg

Answer 5

Token Based (Security / Authentication)

This means that in order for us to prove that we’ve access we first have to receive the token. In a real-life scenario, the token could be an access card to the building, it could be the key to the lock to your house. In order for you to retrieve a key card for your office or the key to your home, you first need to prove who you are and that you in fact do have access to that token. It could be something as simple as showing someone your ID or giving them a secret password. So imagine I need to get access to my office. I go down to the security office, I show them my ID, and they give me this token, which lets me into the building. Now I have unrestricted access to do whatever I want inside the building, as long as I have my token with me.

What’s the benefit of token-based security?

If we think back on the insecure API, what we had to do in that case was that we had to provide our password for everything that we wanted to do.

Imagine that every time we enter a door in our office, we have to give everyone sitting next to the door our password. Now that would be pretty bad because that means that anyone inside our office could take our password and impersonate us, and that’s pretty bad. Instead, what we do is that we retrieve the token, of course together with the password, but we retrieve that from one person. And then we can use this token wherever we want inside the building. Of course, if we lose the token, we have the same problem as if someone else knew our password, but that leads us to things like how do we make sure that if we lose the token, we can revoke the access, and maybe the token shouldn’t live for longer than 24 hours, so the next day that we come to the office, we need to show our ID again. But still, there’s just one person that we show the ID to, and that’s the security guard sitting where we retrieve the tokens.

Excursionist

Access Card feels like a poor analogy for tokens - in that after proving who I am and obtaining an access card, I can freely hand it to anyone to come and go as they please. There is no checking that the access card belongs to the holder, at the time of access. Isn't that closer to API key usage pattern rather than a token? – Bangup

Answer 6

The question is old and the technology has advanced, here is the current state:

JSON Web Token (JWT) is a JSON-based open standard (RFC 7519) for passing claims between parties in web application environment. The tokens are designed to be compact, URL-safe and usable especially in web browser single sign-on (SSO) context.

https://en.wikipedia.org/wiki/JSON_Web_Token

Marcello

I do not think that JWT represents the current state of technology for implementing token based authentication. It is just one way of implementing it and with many flaws which are eloquently put by articles such as cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions – Beacon

Answer 7

It's just hash which is associated with user in database or some other way. That token can be used to authenticate and then authorize a user access related contents of the application. To retrieve this token on client side login is required. After first time login you need to save retrieved token not any other data like session, session id because here everything is token to access other resources of application.

Token is used to assure the authenticity of the user.

UPDATES: In current time, We have more advanced token based technology called JWT (Json Web Token). This technology helps to use same token in multiple systems and we call it single sign-on.

Basically JSON Based Token contains information about user details and token expiry details. So that information can be used to further authenticate or reject the request if token is invalid or expired based on details.

Baccivorous

Answer 8

When you register for a new website, often you are sent an email to activate your account. That email typically contains a link to click on. Part of that link, contains a token, the server knows about this token and can associate it with your account. The token would usually have an expiry date associated with it, so you may only have an hour to click on the link and activate your account. None of this would be possible with cookies or session variables, since its unknown what device or browser the customer is using to check emails.

Gynarchy

One-time token/link is a different concept than token based authentication. – Specie

The name of what you say is also token. But that's not the question – Axe