Refresh token lifetime, error AADSTS50076

[LukeMarlin]

Hi, I've switched our production to the new model and I'm therefore using refresh tokens.

However, in less than 24h, I usually start getting AADSTS50076 on all of my calls. The error message states:

Spoiler

Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access 'SampleBECApp'

Contrary to the error message, I've got this error without moving nor doing anything on the tenant configuration. Since this is now in production, I really need to know what's causing this "change" detection on Microsoft side.

Here are the Ids of a request that failed after ~3h of lifetime of a refresh token (with no actions on my side in between):

Trace ID: 558dc046-59d0-44c4-8fde-214edfc55500

Correlation ID: b7e8f17a-cd0b-48d0-a339-20f2a0d69de5

Timestamp: 2019-02-11 08:21:10

[JanoschUlmer]

@LukeMarlin 

Expired again after 24hs? Or some other timeframe? And again the same error message that configuration was changed and thus token expired? And you have not configured token lifetime to a custom value?  For the test setup I have Refresh token is valid, as expected, for several weeks at least (just used one generated End of July).

So the complete approach you are using would be interesting., However, you can also contact support or ask for help within an Advisory ticket.

 - If you are sure that you have done everything correctly and it has to be service issue affecting your tenant only, contact technical support for AzureAD - e.g. via Azure Portal.

 - if you want a Partner Technical Consultant to check your approach and offer technical advice, contact the technical PreSales & Deployment Services Team (TP&D). askpts@microsoft.com can no longer be used to open a ticket, this request has to be opened via Partner Center (The Partner Center you are using to manage your MPN membership): https://aka.ms/tpdmsform (Note: Send me a pm including your contact details, phone number when you still have troubles opening the ticket yourself).

[idwilliams]

Hi Luke, 

I am adding @aamini to the thread, so he can comment as well. By chance are you using conditional access? 

[LukeMarlin]

Here's the screenshot of conditional access section.

Side note: it happened again.

{'error':'interaction_required','error_description':'AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access \'SampleBECApp\'.\\r\\nTrace ID: 9570779e-0ce7-4bc0-aff7-ab40572fa600\\r\\nCorrelation ID: 09b81afe-7f5f-4571-bd67-61b45a62d135\\r\\nTimestamp: 2019-02-12 09:15:17Z','error_codes':[50076],'timestamp':'2019-02-12 09:15:17Z','trace_id':'9570779e-0ce7-4bc0-aff7-ab40572fa600','correlation_id':'09b81afe-7f5f-4571-bd67-61b45a62d135','suberror':'basic_action'}

[idwilliams]

Hi @LukeMarlin,

Typically when you encounter this error it is an indication of conditional access, see What is the location condition in Azure Active Directory conditional access? if you would like to learn more about this feature. However, since you do not have any policies we can rule this out as the cause. Through my testing I have been using Azure multi-factor authentication and I have not been able to reproduce the issue you are encoutering. To continue troubleshooting this it would be helpful to know what you are using for multi-factor authentication. Also, are the request originating from the same location each time? 

[LukeMarlin]

Hi,

Sorry for the delay, I was on holidays. The issue still goes on.

The 2nd factor is a phone code.

Yes, the request originates from the same machine. It's a user that has been dedicated to a program and it's therefore not used anywhere else. Note that it seems really close to a 24h cycle, might it be possible that there is some kind of "hidden" policy on my tenant?

Also, using the correlation ids I've provided, can't you check on your side if the locations stay the same, or even better, what invalidates my token?

[idwilliams]

Hi @LukeMarlin,

The only other time I have seen an error like this persist is when you are authenticating using user credentials when MFA is enabled. This happens because the user either need to authenticate interactively or by using the refresh token. I am not saying this is what you are running into, but I would recommend that you are using the following process to obtain access tokens for all operations involving the Partner Center API

1. Obtain the refresh token from the secure location where you stored it
2. Request a new access token using the refresh token 
3. Perform the request to the Partner Center API/SDK using the access token obtained above

In addition to this I would recommend that you review the How to validate your solution blog post. That will help you ensure there are not any issues with your process that could be causing this behavior. 

[LukeMarlin]

Hi @idwilliams ,

I've got answer from you since my answer at "02-27-2019 06:10 AM".

Since we're supposed to go back to the secure model + MFA, I'm pretty sure I'll run into the same thing.

Could you take another look at it?

Also, you mentionned that the cause could be conditional access policy (which I do not use yet), and it seems to be the way to enable MFA now as per "https://docs.microsoft.com/en-us/partner-center/partner-security-requirements", does that mean I shouldn't do it like that?

[LukeMarlin]

As expected, it happens the same way as before.

We REALLY need some help regarding this so we can comply to the new model.

I generated a token with MFA two days ago in the evening, and 24h later, I received errors.

A call made this morning before generating a new token:

"{"error":"interaction_required","error_description":"AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access 'SampleBECApp'.\r\nTrace ID: 08dcfd5e-e516-4389-
8b59-b30bca52b400\r\nCorrelation ID: f059f25d-0f63-409a-8964-ed01e965d56c\r\nTimestamp: 2019-08-08 07:54:19Z","error_codes":[50076],"timestamp":"2019-08-08 07:54:19Z","trace_id":"08dcfd5e-e516-4389-8b59-b30bca52b400","correlation_id":"f059f25d-0f63-409a-8964-ed01e965d56c","suberror":"basic_action"}

To recap:

-We made no change whatsoever during this period

-We use phone call as 2nd factor (activated on the old MFA portal)

-All calls with this token are made by a service on a VM, so no environment/ip change either

-There are multiple calls issued per hour except during the night when less happen, so it should NOT go stale

-Sample code posted in another post in the topic if you need it

The topic being opened since november, and MFA being a strong requirement now, I'd greatly appreciate your help here @idwilliams @aamini 

[idwilliams]

@LukeMarlin I have two questions that might help us determine what is happening 

1. What are you using to enforce MFA? Is it per-user enforcement using Azure MFA?
2. After you generate an access token using the refresh token that was generated with an account that has MFA enforce can you decode the token using https://adfshelp.microsoft.com/JwtDecoder/GetToken? I am looking to verify that you see both PWD and MFA in the AMR section

[Alexw]

Apoligies to hijack/ressurect this forum post. However, we're seeing the same issues and I'm really struggling with the documentation provided to get this to work properly.

I was generating an access/refresh token with the following powershell commands. However, it's not prompting for MFA, not does decoding the access token state MFA is being used:

$credential = Get-Credential

# $partnerToken = New-PartnerAccessToken -Scopes 'https://management.azure.com/user_impersonation' -ServicePrincipal -Credential $credential -ApplicationId $appID -Tenant $tenantID -UseAuthorizationCode

Is this an issue with the way we are retrieving the access token, or MFA settings on the account being used?

[JanoschUlmer]

If 

$credential = Get-Credential

 does not trigger MFA, it is something about the account's MFA settings.

Maybe some ip-/network exclusions? MFA state only set to enabled instead of enforced? Conditional Access exclusions? End-user protection baseline policies or AAD security defaults used and user does not have admin roles (since those wil only trigger mFA when risky sign-in is detected)?

You can check AzureAD sign-in logs what happened during authentication.

[LukeMarlin]

Hi @idwilliams ,

1) As mentionned above, as we're using the old portal, yes this is per-user. We cannot use the baseline as we cannot use the authenticator app.

2) Regarding the token itself, here is an extract of the claims for one I've just generated:

"amr": [
"pwd",
"mfa"
],

Is there anything else I can provide to help you?

[idwilliams]

@LukeMarlin thank you for sharing this information. Based on the information you have shared the most likely reason this is happening, is that the MFA claim has expired. This configuration is controlled through the multi-factor authentication service settings. The screenshot below shows the configuration that controls the lifetime of the MFA claim

[LukeMarlin]

Simple as that 😕

That raises some other questions though:

• After issuing a token request, if I replace my refresh token with the new one, will I still be required to redo the 2nd factor on a subsequent request?
• Is it possible to just have unlimited time?
• Is setting it to 60 days (or infinite) compliant with the new secure app model?

Disclaimer: I didn't try yet, but the number is indeed 1 for now so I'm pretty sure you were right on the cause.

[LukeMarlin]

@idwilliamsIt seems that with the bigger number, the token stays fresh, thank you!

However, the three questions above still stand.

I'll also add a 4th: can we set this setting to only one user? I'd prefer to have normal users at on a lower retain period 🙂

[idwilliams]

@LukeMarlin I am glad to hear that your refresh token is staying valid longer. 

• After issuing a token request, if I replace my refresh token with the new one, will I still be required to redo the 2nd factor on a subsequent request?
  
  No, you will not be prompted to reperform the second factor of authentication. Any access or refresh token that is generated using orginial refresh token, that was generated with an account where MFA was enforced, will have the appropirate claims.
  
  
• Is it possible to just have unlimited time?
  
  No, currently this is not possible. The maximum age for a refresh token is 90 days. 
  
  
• Is setting it to 60 days (or infinite) compliant with the new secure app model?
  
  I believe that you are asking about the Azure MFA service setting. If this is correct, then modifying this value will not have any impact on the compliance with the partner secuirty requirements because the accounts still have MFA enforced.
  
  
• Can we set this setting to only one user? 
  
  No, this is a tenant wide setting. By default the value is 14 days if I remember correctly.

[LukeMarlin]

Thank you @idwilliamsfor the answers.

I might have been unclear on the first one, so I'll rephrase it as that's my only question left (finally!).

What I meant to ask was: is the refresh token issued by the access token request "fresher"? Meaning that if at each access request I replace my refresh token with the new one for next requests, will I ever be asked again to do the 2nd factor?

Scenario:

  - set the maximum age to 1 days

  - do a call on day 1, receive a new refresh token along the access token

  - on day 2, use the new refresh token to make a new call <= Will that work, or will the 2nd factor have expired?

That would be a really the best scenario for us!

[LukeMarlin]

Hi,

Still looking for the answer to that question!

Please help me move on to something else 😞

[JanoschUlmer]

Yes, the new refresh token will also have a new lifetime. So if you repeat the process before the refresh token expires, there is no need to do MFA again.

[LukeMarlin]

Hi,

We implemented the refresh refresh-token mechanism 2 weeks ago, and we still received the expired token issue.

Are you positive that using the refresh-token received along with the access token should prevent this?

In that case it means we have an issue with the way we did it and I'll run more controlled tests on my side.

Might it be because it is set to expire in 60 days? Meaning that we simply need to untick the expiration box entirely?