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?

  • 2
    that benefit list is inaccurate; mobile for example has nothing to do with such server IO (or not), and tokens are initially less scale-able. It's mainly about not airing your business all the time, leaving credentials in cache/client machines, or allowing long-term replay attacks.
    – dandavis
    Feb 20, 2017 at 13:46

2 Answers 2


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))

  • 1 - How do you handle tokens on mobile? It's my understanding mobile doesn't use cookies.
    – stk1234
    Jul 4, 2022 at 18:45
  • It seems like the key benefit to tokens is reduced probability of grabbing a piece of information (the password) that may be a single point of failure. Unless there are mechanisms in place like making the user use 2fac or restricting user-pass combinations by IP, the password is pretty likely a single point of failure. 2fac may be arduous to users (although you should probably do it anyway). IP restriction may be hard to enforce unless there is a VPN or something.
    – stk1234
    Jul 5, 2022 at 1:04
  • #1 - No Token - password exposed in every network request client -> server
    – stk1234
    Jul 5, 2022 at 1:05
  • #2 - With Token - password only exposed once in a network request client -> server; token exposed every other time
    – stk1234
    Jul 5, 2022 at 1:05
  • When it comes time to expire either the password or the token, either will require the user to log back in with their password. Password reset case requires "old password" to create new password and refresh token would just require password. If someone has stolen a password (higher pr in scenario #1), either way they’ll get back in. If someone has stolen a refresh token, they’ll be SOL when refresh time comes. Is that correct?
    – stk1234
    Jul 5, 2022 at 1:06


  • 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.


  • 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.

  • The point about MitM does not make sense here - if there is a successful MitM attack, the attacker can probably read all requests, so it does not matter much whether the password is sent with each request or only once (to get the token). The session management aspect is good, though.
    – sleske
    Apr 20, 2020 at 14:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .