Oauth 2.0 - MFA for REST APIs

Question

We are looking at implementing Multi-factor authentication for our application, using Time-based one-time password (TOTP) algorithm.

What we want to achieve:

• Users should have the option to enable Multi-factor authentication for their account. Once enabled, they will be prompted for the

• Authorization code (which they need to get using an Authenticator app)

It is clear, how the flow should work - registering for the MFA, showing the QR-code etc. But I have a few questions around the general architecture of the flow - especially for the REST API's.

Firstly, lets say we implement it for the web application. Once a user reigsters for MFA, we ask need to also ask for the Authorization code. But what do we do with the REST API's - I would think we need to also enable MFA there (Oauth2 login)

If so, how do we make sure the different client applications that might be using the API - are not affected? I would think all the apps need to migrate to the new way of logging in - before we allow the users to register for MFA.

One way we are thinking of achieving this:

• When the user tries to logs in, we check if MFA is enabled.
• If not, we login the user
• If yes, we give an error that is understandable by the client that - and they ask for the authorization code
• The user logs in by providing the correct authorization code

But it still has the problem of the client applications not implementing the flow - and hence the user being locked out.

Mostly, I am not clear on how best to implement MFA for the REST API's - Maybe there is a better way?

Answer 1

Firstly, lets say we implement it for the web application. Once a user reigsters for MFA, we ask need to also ask for the Authorization code. But what do we do with the REST API's

Exactly the same.

In a RESTful API messages are self-descriptive. This just means, that there is a meaningful media-type and the client reacts (as opposed to hard-code) to what the server sends, whatever that may be.

So in my application for example, if the server (at any point in the flow, as a response to any request) sends a login page, the client knows to log in, because it reacts to the login page the same as a human user would do. If after the login page I were to to add an OTP authentication page on the server, all the exiting clients would still properly authenticate if that page is not enabled for the given user. If the user would enable the OTP, the old clients would throw an error, because they would not know what an OTP authentication page is (they would not know the media-type). Once they do know how to react to it, they would continue to work as expected.

I don't know whether that helps you, but this would be the "RESTful" way of doing it.

Addendum: I consider authentication a part of any "RESTful" API. My APIs always start with one URI where you don't need any special headers to start. From there on you only need to react to media-types you receive. The server will prompt you for anything it may need, including authentication, at the time it needs it.

Answer 2

Firstly, lets say we implement it for the web application. Once a user reigsters for MFA, we ask need to also ask for the Authorization code. But what do we do with the REST API's - I would think we need to also enable MFA there (Oauth2 login)

Remember MFA is about verifying the user's identity as part of their login journey; this happens before the identity server issues an authorization code.

Access tokens are completely unaffected by MFA, the effects of enabling MFA are in whichever code currently prompts the user to enter their credentials.

if the credentials step of the user's journey is currently part of client applications themselves then enabling MFA will cause the identity server to return a different response after the user's credentials are checked.

Following the TOTP check, all of the OAuth2 flows remain exactly the same; the process to exchange an auth code for tokens will be unaffected - the endpoints are the same, and so are the responses; indeed the tokens themselves will be exactly the same.

REST APIs generally only handle tokens, usually using an Authorization header in each HTTP request. It generally doesn't make sense for a REST API to prompt users for their credentials or indeed be involved in any way in their login journey; therefore those APIs should be unaffected and unaware of the change to use MFA, continuing to consume tokens in exactly the same way.

But it still has the problem of the client applications not implementing the flow - and hence the user being locked out.

There is no way of avoiding the fact that the user's initial login journey (before receiving the auth code) has to change to support MFA.

If client applications are currently implementing that journey themselves (prompting for credentials) and MFA is enabled then those applications will receive a different response from the identity server after MFA Is enabled, so those client applications must implement the TOTP step of the journey.

---

The relative ease or difficulty of making this change inside those applications depends entirely on the way each of those applications has designed its handling of the journey. A common approach is for client applications not to actually implement the user's login journey themselves but redirect the web browser to a separate dedicated external 'login' app, then receive an auth code via a 'callback' URL (a 302 redirect in the web browser).

If you want to make this as simple as possible for your client applications and reduce duplication, then you may consider building a separate dedicated client login app to take care of the authentication journey; you could offer this app to those teams who control those client applications as a "quick win" which may save them some time and allow them to strip out their own login journey.