20

I know this might seem like a trivial question but I can't find the answer for it to at least put my mind at peace.

If a mobile app is communication with a server then typically they sign in and they get an access token that they can use for the remainder of the session with any future request.

WHY not just pass the user name and password over HTTPS with every request instead of the access token. An access token will need to be verified with database and so is the combination of username/password. Why go through the added effort of access token if they do the same thing? I know I am missing something but I can't figure it out.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Snake
  • 14,228
  • 27
  • 117
  • 250
  • 2
    This would probably be more appropriate on [security.se], but the very quick answer includes that using OAuth means the client app never sees the user name and password, and the access token can have a more restricted set of rights than the full password. – Ken Y-N Dec 25 '18 at 06:49
  • 2
    There are many related questions about that on https://security.stackexchange.com , such as [Why use an authentication token instead of the username/password per request?](https://security.stackexchange.com/questions/63435/why-use-an-authentication-token-instead-of-the-username-password-per-request), and [Token based API security over repeated username/password requests](https://security.stackexchange.com/questions/151770/) – sleske Apr 21 '20 at 06:45

3 Answers3

17

You are right in that an access token is verified pretty much the same way as a username and password. For the period when the access token is valid, it is pretty much equivalent to the username and password. In some cases (depending on your threat model) it may even be ok to send username and password with every request, maybe not from a mobile app, but for example in server to server requests, with appropriate controls.

However, you don't want to send the password in every request from a mobile app primarily because then you would have to store it.

The problem with a password (or with users, actually) is that they are reused. A password is a valuable target, because the same password is likely to be used on multiple services. So you exchange it for a shorter-lived access token, which, if stolen, presents less risk for your user. And you can't easily revoke a password - forcing users to change their passwords is a hassle. Revoking an acces stoken is easy.

Also it's very unlikely, but sometimes there are vulnerabilities in TLS - not very often, but there have been a few in the past years. Such a vulnerability might allow an attacker to decrypt some of the traffic sent over https, or for example there was a vulnerability in openssl a while ago that allowed attackers to extract parts of the server memory, potentially holding whatever the user(s) sent. It's much better if it's just an access token, and not the actual password.

Another point is sometimes (in OAuth flows) your app won't be allowed to even access the actual password. When your user logs in with a 3rd party identity provider (like for example facebook), they would not like your app to receive their facebook password. They just go to facebook, exchange their credentials for an access token, and you only see the token which you can verify with facebook if you want. But you never actually get the user's facebook password. Of course this is only valid when the identity provider is a third party.

Gabor Lengyel
  • 14,129
  • 4
  • 32
  • 59
  • Thank you for the collaborative response. When you say that the password needs to be stored, the wouldn't storing it in memory of mobile app be safe? My intention is to store password or access token in the memory which means the moment the application is killed everything is wiped off and it is not local storage .am I overseeing something here ? Also, If someone has access to the access token (say decrypted) then that person can do the same api request untill it it is blocked or expired, right ? – Snake Dec 25 '18 at 07:26
  • Storing the token only in memory would probably be the most secure, but it has serious user experience consequences (ie. the user has to log in again all the time - not the usual mobile app experience). For many apps (depending on the sensitivity of the data managed) it's ok to store the token in an appropriate store provided by the mobile OS. And yes of course, if somebody has the access token, they can make any request that is allowed with that access token. – Gabor Lengyel Dec 25 '18 at 08:04
6

I think the answer is all about the security and safety.

IT'S ALWAYS RECOMMENDED to use access tokens instead of username & password, because:

  • Access tokens (in most services) can be easily generated, blocked, monitored for their usage & statistics from your account, can be set as expirable, can have restricted permissions, and so on... Of course, you can delete it at all. The Username & Password is the master, who can control the access tokens.

  • Access tokens are safer as I said, and that is the most important thing. If you use Username & password in your web-application (or whatever) and that application is hacked (which happens so frequently), or someone views its source, or even some log-system saves the request parameters - then your user & password can be viewed by 3-rd parties and all your account can be hacked (and probably others too, where you have same user/pw). Access tokens eliminate all these risks.

  • About speed - I don't think that authorization with USER & PW has any significant advantage in speed.

T.Todua
  • 53,146
  • 19
  • 236
  • 237
  • 1
    Username/password access can be blocked, monitored, expired and assigned to permissions the same way as an access token. Also it's a side point, but a 100 ms delay in every request would be quite a lot for many applications. :) But you're right that it doesn't matter whether you check an actual password or an access token. Sometimes access tokens are validated on online services though (the identity provider that issued the token), in which case it's not just a database lookup. – Gabor Lengyel Dec 25 '18 at 07:09
  • Thank you, when you say safer you mean safer in the long term not short term .right? I mean if someone has access to the access token then he can do the same api calls until token is revoked (giving access in short term ) – Snake Dec 25 '18 at 07:27
  • @Snake Safety doesn't recognize "short" or "long"-term - i mean, if someone can get into source-code of your app, then he can see your stored (even encrypted) username and password. So, it's better, to put access-tokens under the risk, than U&P. – T.Todua Dec 25 '18 at 08:30
0

I can think of several reasons why.

  1. If your password is stored locally in your browser then that means that if you leave your PC or phone while you are logged in and someone else sits in front of a computer they will have means of seeing what your password is. On the other hand, if the only thing that they can see is an access token then they basically didn't gain anything. That token will expire as soon as you log out.
  2. If you constantly pass your password to the server and your connection gets interrupted by hackers they now have your password. On the other hand, if all you send is a token, then that token is meaningless as it expires as soon as you log out (not to mention that token may be related to your IP address and thus it can be unusable for them).
  3. This is related to the first two reasons. What's the point of asking you what your password is when you want to do some sensitive stuff with your account and what's the point of asking you what your current password is when you want to change it if you have access to your current password in your browser? You are already sending it with every request and every neferious actor that sits in front of your PC or phone and every neferious actor that interferes with your PC's or phone's connection to the server has your password.
catloverxx
  • 47
  • 8