Failure to generate access token using refresh token for O365 API

Question

I'm getting invalid_grant error while generating access token using refresh token

POST https://login.microsoftonline.com/common/oauth2/v2.0/token

Response

{
  "error": "invalid_grant",
  "error_description":
    "AADSTS50173: The provided grant has expired due to it being revoked. The user might have changed or reset their password. The grant was issued on '2018-06-13T23:20:02.9860000Z' and the TokensValidFrom date for this user is '2018-06-15T17:21:11.0000000Z'\r\nTrace ID: 4237d0b8-51fe-43c2-9b5c-ca9148175400\r\nCorrelation ID: d192091b-6277-4ef9-859a-87ba7f87491a\r\nTimestamp: 2018-06-18 07:22:59Z",
  "error_codes": [50173],
  "timestamp": "2018-06-18 07:22:59Z",
  "trace_id": "4237d0b8-51fe-43c2-9b5c-ca9148175400",
  "correlation_id": "d192091b-6277-4ef9-859a-87ba7f87491a"
}

The user was asked to change password and the password was changed. Seeing this error even after the password is changed. Will the refresh token become invalid in this case?

Solution 1

If you get this error while using the azure-cli You can fix it by:

az account clear

az login

That happened because after you change your password, tokens that are based on passwords will expire. Then you need to clear your account and log in again.

More information here

Solution 2

Yes, refresh tokens will become invalid after a password change.
Only non-password based tokens will stay valid.

(see active directory token documentation for more information)

Solution 3

Environment: Office 365 - Okta - On-premise Active Directory.

Error message:

The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password. The grant was issued on '{authTime}' and the TokensValidFrom date (before which tokens are not valid) for this user is '{validDate}'.

Workaround:

All you need to do is temporarily change the user’s UserPrincipalName to that of a managed domain, update the password and then change the UserPrincipalName back to the federated domain.

First step is you will need to get the user's ObjectId and UserPrincipalName.

1. Run this command to get the ObjectId and the user's UserPrincipalName:

   Get-AzureADUser -SearchString pat.doe
   

2. Now, run the following command to change UPN to a managed domain:

   Set-AzureADUser -ObjectId 11bb4111-11a0-1114-8501-111180bf51d3 -UserPrincipalName [email protected]
   

3. Next, update the password with the following command:

   Set-AzureADUserPassword -ObjectId 11bb4111-11a0-1114-8501-111180bf51d3
   

4. Change the UPN back to the federated domain. Run the following command:

   Set-AzureADUser -ObjectId 11bb4111-11a0-1114-8501-111180bf51d3 -UserPrincipalName [email protected]
   

That’s it. Now, reset the password in Okta or the Authoritative source (Active Directory).

Comments

[Surakshith]

Thanks for the reply! I did a quick test and I could see that the refresh token is valid when the user changes the password, but the refresh token will be revoked only when the password expires in AD and user is forced to reset. This behaviour is not consistent with the one mentioned in the documentation.

[Karlheinz Reinhardt]

After the user did change his password: how long did you wait until you tried to fetch a new refresh token? Maybe the refresh-token in not revoked instantly? Maybe there is a different revokation "delay" between 'user changes pw himself' and 'pw expires in AD'

[Surakshith]

I changed the password around 7 hours back and I'm still able to use the same refresh token to generate access-token. I'll wait for some more time and will check the refresh token expires.

[Karlheinz Reinhardt]

did the user itself change the password or did an admin change the password for the user? Other than that I have no idea what could cause this behavior. Sorry that I cant help you.

[Surakshith]

In this case, the user changed the password and the refresh token is still valid. But when the user is forced to change after expiry the refresh token is revoked

[Marc LaFleur]

This has been the case for a while, and I agree that the documentation is unclear. The rules seem to be take tokens are revoked if a) Admin revokes them, b) User revokes them, c) an Admin changes the password, or d) the password expires/user foced to reset. If the user simply changes thier password, it seems to leave existing tokens active. '

[veuncent]

Note: in my case az account clear was not necessary