I am currently working on an App and just got the authentication API. And, I am a bit confused. Mainly about why the API uses a password when it also uses access and refresh tokens.
The API (for simplicity's sake) has four endpoints. /register, /verify, /refreshToken and /login.
The authentication process is passwordless (for the user). You get an OTP-Code via SMS.
The process starts with the user entering his/her phone number. Then the app should generate a password, behind the scenes, which it also stores for later use. After that /register is called with the phone number and password. The server then sends an SMS OTP-Code to the user’s phone.
The user inputs the the OTP-Code. Then /verify is called with the OTP-Code and the stored password. This call returns an access and refresh token.
/refreshToken When the access token expires /refreshToken is called. It takes in the phone number, refresh token and the password from storage. The server returns a new access and refresh token.
/login When even the refresh is expired (which it does fairly quickly) the app calls /login. It takes in the phone number and password from storage. The server then returns a new access and refresh token.
I have multiple issues with API.
Firstly, it uses a password which is generated by the app and is not known to the user. Meaning, when the user resets his/her devices the app needs to generate a new password. That can be done using the OTP-Code, tho.
The /login endpoint makes the /refreshToken endpoint useless and is also able to get new tokens even if the refresh token is expired. In my mind, that completely bypasses the concept behind the tokens.
The /refreshToken endpoint also needs the password.
Isn’t the purpose behind the tokens that you don’t need to use a password to re-authenticate?
I am not too familiar with authentication. Do I just not understand the API?
I am also talking to the devs making the API. I just want to get a third opinion here.
Thank you for your help. I hope I was able to explain the issues :)
CodePudding user response：
I would like to start by saying, that different applications have different security requirements around authentication, so what is acceptable for some, might not be acceptable for others. Having said that, let's try to understand what is going on here:
- First of all, the thing you have named password is not really a password. It is a secret shared between the client and the server. It makes sense, because it protects the SMS channel from MitM attacks (meaning: even if someone fetches the OTP code, he will not be able to log in).
- Having access and refresh tokens makes sense. We usually exchange the credentials/MFA-secrets/biometrics to get the access and refresh tokens.
- Having the password-secret stored and the possibility to reuse it to regenerate the tokens is wrong given the system architecture we have seen so far. It completely invalidates the need for the refresh token. Suddenly there seems to be a static secret to regenerate it all. It also makes the SMS channel not really needed here.