Differentiate between expired and invalid access token

[Nitesh_Shrestha]

Is there way to differentiate between invalid and expired access token?

[#2]

If you have the OAuth policy, the error message should tell you whether the access token is invalid or expired:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="verify-oauth-v2-access-token">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <Operation>VerifyAccessToken</Operation>
</OAuthV2>

You should get an error message like this, if the access token in invalid or if you have not passed it:

{
	"fault": {
		"faultstring": "Invalid access token",
		"detail": {
			"errorcode": "oauth.v2.InvalidAccessToken"
		}
	}
}
<br>

and this if it has expired:

{
  "fault": {
    "faultstring": "Access Token expired",
    "detail": {
      "errorcode": "keymanagement.service.access_token_expired"
    }
  }
}

If you want to handle this within the fault rules/message pipeline, the flow variable error.message will also give you the same message ``Access Token expired`` if the access token is valid but expired and ``Invalid access token`` if incorrect access token is passed of it it is not passed.

You can verify that by adding a policy like this:

<AssignMessage async="false" continueOnError="false" enabled="true" name="add-error-message">
    <DisplayName>add-error-message</DisplayName>
    <FaultRules/>
    <Properties/>
    <Add>
        <Headers>
            <Header name="test-error-message">{error.message}</Header>
        </Headers>
    </Add>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

And assigning it to your fault pipe line. You should see the header with appropriate value based on the scenario

<FaultRules>
       <FaultRule name="default">
            <Step>
                <Name>add-error-message</Name>
            </Step>
            
        </FaultRule>
    </FaultRules>

[Nitesh_Shrestha]

Thanks @Sandeep Murusupalli.

My bad, actually I was looking to differentiate same for refresh token. And as per this post

is-there-a-verify-refresh-token-policy there is no way to differentiate.