Conditional multi-factor rule removes permissions from JWT

Hello,
In my setup the API has RBAC enabled as well as Add Permissions in the Access Token.
At the same time there is a conditional MFA rule as following:

function (user, context, callback) {
if (context.clientID === ‘’ && user.user_metadata.use_mfa !== “false”) {
context.multifactor = {
provider: ‘any’,
allowRememberBrowser: false
};
}
return callback(null, user, context);
}

Whenever use_mfa is false (no multi-factor) the permissions are properly added to the JWT. However, when use_mfa is true, permissions are missing.

Please help! This had me running in circles for awhile :frowning:

Alex

I was unable to reproduce this in a lab environment with only that rule enabled; for reference here’s the steps I did:

  1. create a user, API and client application.
  2. enable RBAC in API, set a permission directly to the user and configure user metadata to not request MFA.
  3. login with the user and confirm the permissions are there in the token.
  4. enable MFA in user metadata.
  5. login again with the user.

In the last step I still saw permissions in the access token.

Can you confirm that is the only rule you have enabled in the tenant? If it is not it would be worthwhile to test with all other rules disabled and also provide more information about how you’re performing the login. For example, I used the new universal login experience to complete my test logins.

Thank you for your response!

This rule is the only rule in the tenant. Removing it, brings permissions back into the JWT.

The users in the app are required MFA on a certain condition. The use_mfa flag is set to true when it is required. Type of the flow that is used here is username/password and a DB connection.

Can you share a sample access token for the two scenarios (with rule and without rule)? You can remove the signature part to make the token useless and if you want to go beyond you can just include the JSON payload with redacted personal information.

If you redact information please replace it in a consistent way in both tokens and use equivalent data. For example, if both tokens contains a user email address john.doe@example.com replace it by user@example.com in both.

Here is the token with MFA (signature removed):

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik5rVXpRVE0xTnpReE16azJPRFl6UlRSRE1USTFRall6TmtKRk16TkZNMEUzUTBNM1FUUTRRUSJ9.eyJpc3MiOiJodHRwczovL2Ryb3BmaXRuZXNzLmF1dGgwLmNvbS8iLCJzdWIiOiJhdXRoMHw1ZTBlMGE0NWMzMzQzYjBmMzEzNDc4ZTgiLCJhdWQiOiJodHRwczovL2Ryb3BmaXRuZXNzLmNvbS9hcGkiLCJpYXQiOjE1Nzc5Nzg1MDAsImV4cCI6MTU4MDU3MDUwMCwiYXpwIjoiSWRtTzNjUTZFUVJadTJNNm9NcGhpMDI3VHZzc2pJVGEiLCJndHkiOiJwYXNzd29yZCJ9

This one is without MFA:

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik5rVXpRVE0xTnpReE16azJPRFl6UlRSRE1USTFRall6TmtKRk16TkZNMEUzUTBNM1FUUTRRUSJ9.eyJpc3MiOiJodHRwczovL2Ryb3BmaXRuZXNzLmF1dGgwLmNvbS8iLCJzdWIiOiJhdXRoMHw1ZTBlMGJhNjUyZWU0ZTBmNGU0ZGI4ZTkiLCJhdWQiOiJodHRwczovL2Ryb3BmaXRuZXNzLmNvbS9hcGkiLCJpYXQiOjE1Nzc5Nzg3OTEsImV4cCI6MTU4MDU3MDc5MSwiYXpwIjoiSWRtTzNjUTZFUVJadTJNNm9NcGhpMDI3VHZzc2pJVGEiLCJndHkiOiJwYXNzd29yZCIsInBlcm1pc3Npb25zIjpbIm1hbmFnZTpzZWxmIiwicmVnaXN0ZXI6bWVtYmVyIiwic2VuZDplbWFpbCJdfQ

The last one has permissions in the payload as expected.

TIA!

Thanks for sharing; I confess that I initially assumed only one user was being used for testing this and that the user profile was just updated to toggle MFA on and off, but for the provided tokens the sub claim is different which indicates different users. With different users there’s much more scenarios that could explain the difference in issued token.

Is it possible for you to perform the tests with the same exact user?

@jmangelo I have the same problem. I did it with the same user, and if user logged in without mfa then permissions is presented, but if use mfa - they omitted
@alex16 is there a solution to this problem?

Now it have been fixed on Auth0 side

2 Likes

Glad it’s working now!