Token based API security over repeated username/password requests

Question

What are the security benefits over a token based API security model versus sending the username & password every time?

The process of the token based approach is:

1. Send a 'login' request with username and password
2. Receive a token
3. Use the token instead of username/password for all subsequent requests

The benefits of a token based system (according to this http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/ ) are:

• Scalability
• Loosely coupled technology
• Mobile friendly

However, I'm not sure why these advantages are specific to a token based approach rather than sending the username/password each time? Is it not just as easy to add subsequent web-servers to a cluster either way? The password verification is still performed in both cases, so the client-side is just as loosely coupled?

Advantages? Is it simply that the username/password does not need to be 'checked' every time and we can do a more simple lookup based on a list of session keys? While this is a performance improvement it does add increased complexity on the client application, and further complexities if there is a timeout on the token where the client would need to check if the token is still valid?

Disadvantages? Are the downsides with a username/password sent with every request that with more and more transmissions of this data it becomes more likely that it could be discovered? If so, is HTTPS not robust enough to counter this threat?

EDIT: I have read this potential duplicate: Why use an authentication token instead of the username/password per request? but I am a little unsure why point #2 states that the username/password would be stored as a cookie. Why would the client machine keep the username/password as a cookie and not include it in the post content itself?

Answer 1

Why would the client machine keep the username/password as a cookie and not include it in the post content itself?

Keeping username/password (or token for that matter) in a post content, localStorage or sessionStorage exposes this content to a XSS attack. Please see this article. Even though the article is about a token, the same principle applies for any credentials (including username/password). Some more references about this here. If you store such information in a httpOnly cookie, the content is not available to JavaScript and thus theoretically imune to an XSS attack. Once you have your credentials in a cookie, you are open to a CSRF attack and you need to handle it.

Answer on your linked question is correct.

I would add another benefit for token: expiration. If username/password credentials are stolen, it might be difficult to detect it. Tokens will expire at some point and the user will need to relogin to be allowed new one. This limits the timeframe where a stolen token can be used to authenticate on the server. In case of username/password credentials, there is no such limit or it is larger (password expiration policy is usually a month or more where a token can be set to expire in minutes or day(s))

Answer 2

Username/Password

• It is not a good idea to send credentials with each API requests. Even though you are sending credentials over ssl/tls(doesn't provide end-end secure tunnel, known vulnerabilities !!), there are high chances of client being victim of MITM(Lan/Wifi level, ISP level, Country level) attacks.

• Username(name, email)/Password(not too complex) are easily guessable. Definitely you would not want your users to enter 21+ characters password right ? for a better user experience !

Token Based

• 1 token(with expiry time untill user logout) is same as Username/Password

• You should try implementing Oauth, JWT or Custom access/refresh token scheme. This approach itself will not provide more security if you are implementing it wrongly.

With tokens, you can provide users with more flexible session management transparency.

Ex:-

• Kill remote session (expire token !)
• Renew current session (renew access token via refresh token !)
• Keep track of all active sessions
• Token(Random+length) is not easy to bruteforce.

I won't talk about scalability and other benefits here. But yes, you get to scale your service with the token based approach :-) Open em up for 3rd party consumption.