Where should 'reset password' functionality be?

Question

We've recently overhauled the backend to our mobile app from having a very basic authentication mechanism that went through the API to having both an authentication server and an API server, with the auth server issuing OAuth2 JWT tokens (authorization code flow) for login and the API authenticating clients based on these tokens. We open the mobile device's browser, attached to the app, so that the user can enter their credentials straight into the auth server's web interface and the password never has to go through the app, which is a potential security risk.

We've also switched to using the same mechanism of opening the mobile device's browser for our "register user" and "change password" functionality, in both cases because these are also times when the user will be entering a password, and we don't want it to go through the app.

However, I'm not sure about our "forgot password" functionality. This is still using the app's UI to go through the API server at the moment because the user isn't having to enter a password (just an e-mail address to which a password reset link is sent) and so no password is exposed to the app, and as the API and auth server are sharing a user credentials database the API is able to generate the password reset link and store it in the DB, but should we be exposing this functionality on the auth server instead as a web interface similar to how we're doing register, login, and change password? If so, why? What are the pros and cons?

Answer 1

From my experience, it is always recommended to have all identity-based operations in one place. In your use case it is AuthN service which manages the identity.

I would also adice to taking a look into biggest gamers on this market: Google Account, MS Azure AD, GitHub, Twitter. If you have application which uses those identity providers to authenticate users, the reset password feature (and others) are performed on the identity provider. I believe that thay cannot be wrong. What more, also providers of Identity providers solutions like Ping, Auth0, or KeyCloak, are providing own services for this tasks.

The same thing is also in your case. If your are presenting your own Identity Provider (IdP) for your app so you possibly think of possibility to create other client apps which also be using the same IdP. Would you implement "forget password" in that application separatelly? I belive you would not like to repeat yourself. You can implement all forget-password feature best practices in one place and than your would not have bother on any other app.

Summarizing, I recommend to implement that on Auth Server.

Answer 2

I believe there is nothing fundamentally wrong with the way you are implementing the forgotten password functionality.

The process however needs to be implemented securely, or otherwise that link alone could be used to hijack accounts once or more than once:

• Does the forgotten password link work more than once?; It shouldn't so it can't be reused later;
• Does the forgotten password link include an unique not guessable identifier? It should so it can't be guessed;
• Is the user prompted for additional authentication tokens when they follow the link before the password is somehow reset? It should to verify ownership of the account;
• Does the system immediately reset the password when the feature is requested? I shouldn't to prevent DoS against accounts that users know usernames for - the password should not be touched until after the user confirms its authenticity by providing additional authentication tokens;

You may or may not be able to control all of these aspects, depending on whether you control the authentication provider as well.