One of our fellow CTOs asked us a question recently,

“Say you’re using a 3rd party Identity Provider for User Account Management and there are operations that require a SUDO/God mode with elevated permissions assertions (maybe via SMS verification or some other form of assertion such as re-entering the password). How do you do it?”

This is a very good question. We have often seen the need to have elevated permissions to be validated in real-time before critical operations occur so that we know that the user who is trying to perform the operation actually still has the authority to do so, or even better, is actually the person requesting this operation.

Here’s ONE quick way of doing this. Let’s run over the scenario:

1. The User has already authenticated themselves and has logged in the RP (relying party) application
2. Now the user wants to perform an elevated operation. At this point, you would like to throw in a challenge – in this case, the challenge is simply re-verification of the password or some sort of an MFA verification.
3. Once the challenge has been satisfied, you can allow them to continue on.

Irrespective of the IdP you use, the following needs to happen at the application level and not at the IdP level. You will need to create an API level policy that does the following:

1. When any elevated permissions are requested, you will check when the bearer token was issued (date created was available within the bearer token)
2. If it was issued a while ago (configurable) and exceeds the minimum configured threshold, your API will need to send a Challenge result back (a Challenge is simply a way to say that you don’t know or can’t trust the User’s identity anymore)
3. When your UI receives this response, you will direct the User to the IdP Login page to re-login. Alternatively, depending on the policy, they can also request MFA.
4. The User will be forced to login again, or verify their identity using MFA, and the IdP will redirect you to your normal redirect page where you process this token and based on a state variable, redirect the user to the page where you were performing the elevated operation at and it will in essence allow you to run this operation again.
5. Now when you run this operation, the API policy will check and find a more recent bearer token which was recently issued and well below the limits for re-verification and it will let you continue with the operation.

To sum it up, this isn’t something your IdP cares about. Your IdP’s job involves authenticating you, providing you with valid set of claims, generating a bearer token (if you want) and granting access to protected resources by giving you the scopes you requested.