This question already has an answer here:
I have a basic doubt or apparently am missing out on something fundamental. When talking about an Android app that talks to the backend using APIs, the access to the resources/APIs are protected using access tokens and refresh tokens (much like OAuth 2.0).
From what I understand, this is how it works :
- The user open the app and provides his login credentials.
- App makes a POST request to the server and the server issues an access token (random, unguessable token) to the app.
- The app stores this access token securely on the local storage (sqlite db/shared preferences etc.) and uses sends this token with every other API call to let the server know that it is authorized to access the resource.
- Now this access token has an expiry time as well. So that even if the access token gets compromised, somehow, the attack window would be small.
- Now when this happens, it would require the user to renter his login credentials and obtain an authorized access token again, which at least in case of mobile apps, is a bad (not acceptable) user experience.
- So to solve this problem, there is a refresh token that is also issued to the app along with the access token in the first place. This refresh token is a very long lived special token, which makes sure that as soon as the access token expires, it requests the server for a new access token, thus removing the need for the user to re-enter his login credentials to retrieve a new authorized access token.
Now my question is:
how does this solve our original problem of preventing unauthorized access to the APIs ? In my opinion, it actually facilitates it further.
If the access token gets compromised, it's highly likely that the refresh token would also get compromised the same way, isn't it? And because the refresh token is a very long lived token, the attacker would be able to use it (till the refresh token does not expire) to keep generating new authorized access tokens. Is that correct ?
Please help me understand this.