Hi,

You can manage redirects only in the browsers. A better approach could be that the Authorization/Resource server responds with a custom message, for example:

HTTP 403
{"reason" : "need_2fa"}

This makes the client aware of what is going on. Based on this response the client can show a message to the users and ask for 2fa. Next, it could redirect to 2fa endpoint, or open a popup, a new view or whatever.

Another way to manage 2fa is in the login phase. The Authorization server can ask for 2fa after the user login based on the scopes requested. However, this could turn in a “scope management hell” for the Authorization server.

My opinion is that the clients should request 2fa in the authentication request, based on their functionalities. OpenId Connect provides the acr_values (Authentication Context Class Values) parameter, that specifies the client “intents”.

If you don’t use OpenId connect, you can use a custom grant_type, which is supported by the OAuth framework, however, adding custom behavior could be hard, especially in a long time.

Wrapping up:

• if the client knows that it needs 2fa, it should request it during the first authorization request. Using acr_values or other strategies.
• if the client doesn’t know if 2fa is required for a specific resource, it should be able to parse a server error message and then take actions to make the user authenticates with a stronger factor.

Please let me know if this helped.

Lorenzo