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

[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,

Step 1, 2 and 3 is precisely what we do. Here's what we use these steps.

And yes, we do use 2FA as it's going to be a requirement (and should already be without the postpone)

1)

$credential = Get-Credential # appId & appSecret
$token = New-PartnerAccessToken -Consent -Credential $credential -Resource https://api.partnercenter.microsoft.com -ServicePrincipal

# We then store $token.refreshToken

2)

// Truncated code, might miss some lines, it's just to give an idea
private const string loginUrl = "https://login.microsoftonline.com/<our tenant id>/oauth2/token/";
private const string PC_API = "https://api.partnercenter.microsoft.com";

WebRequest request = WebRequest.Create(loginUrl);
request.Method = "POST";
request.ContentType = "application/x-www-form-urlencoded";

string content = string.Format(
"resource={0}&client_id={1}&client_secret={2}&grant_type=refresh_token&refresh_token={3}&scope=openid",
HttpUtility.UrlEncode(PC_API),
HttpUtility.UrlEncode(applicationId),
HttpUtility.UrlEncode(applicationSecret),
HttpUtility.UrlEncode(refreshToken));

using (StreamWriter writer = new StreamWriter(request.GetRequestStream()))
{
    writer.Write(content);
}

WebResponse response = request.GetResponse();
// Extract access token from respons

3) Use the extracted access token to call the PC API with the C# SDK

I didn't try your solution yet, however as far as I understand it'll simply validate that the token was acquired with a 2nd factor, which is something I could already verify by looking at the JWT claims: "mfa" is there. If there's another reason to try it, please tell me so. Also, is there a way to do that in the partner center SDK?

[msallmen]

Was this ever resolved? We seem to have the same scenario with refresh token no longer working after 24 hours.

[cblackuk]

Just so that I understand fully... You get refresh token via user who has got MFA enabled right? Then it will allow you to get access tokens for the first 23 hours but breaks with the MFA-like error message?

I have only seen the error message when I got my refresh token with MFA disabled account but then it never works for MFA enabled Azure ADs...

[msallmen]

Correct. We recently enabled MFA on our service accounts for our applications which call Microsoft APIs. We use the refresh token to get access tokens. Everything works fine for about a day, then generates unauthorized access tokens. Manually establishing a new refresh token resolves this issue for another day. We have multiple tenants with Microsoft. However, this only occurs on our US tenant.

[LukeMarlin]

Hi @msallmen , no, this is yet to be solved, despite that discussion being open for quite some time now! And Indeed, we have MFA enabled.

@idwilliams, Being tired of login with MFA every day, we decided to drop MFA to ease the task. However it seems that now the token survives for more than one day (4th or 5th day today). It therefore seem to be an issue with MFA, and I might not be alone according to other posts here. Can you please bring up this issue so we can reenable MFA safely when the day will come?

[msallmen]

After the refresh token failed to give us valid access tokens every 24 hours for three days, we found this highlighted checkbox.

Uncheck remember multi-factor authentication under the service settings.

We unchecked the highlighted checkbox and generated a new refresh token, and we are past 48 hours of that refresh token working for us. I really thought this would only apply to users logging into the portal; strangely, it seems to have resolved our issue. I'd be interested to know if anyone else has seen this behavior.

[stan]

Yeah I think we are seeing the same thing. We have set this to 14 days and since I have issued refresh token I had to change it twice as it stopped working.

[stan]

@idwilliamsCan we get information if this is bug in Azure AD?

[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?

[luckycharms]

@msallmen Could you share where you found that screen that has the refresh token expiry days? I'm not able to find it

---

@msallmen wrote:

After the refresh token failed to give us valid access tokens every 24 hours for three days, we found this highlighted checkbox.

Uncheck remember multi-factor authentication under the service settings.

We unchecked the highlighted checkbox and generated a new refresh token, and we are past 48 hours of that refresh token working for us. I really thought this would only apply to users logging into the portal; strangely, it seems to have resolved our issue. I'd be interested to know if anyone else has seen this behavior.

---

[ashin]

https://account.activedirectory.windowsazure.com/UserManagement/MfaSettings.aspx?culture=en-US&BrandContextID=O365

[msallmen]

In Azure AD, look at your list of users and find this button.

On the next screen, click the service settings link.

It doesn't even look like a button or link. I had some trouble finding it again myself just now!

[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

[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.