Invalidation of Refresh Token using InvalidateToken not working.

Google Cloud Apigee
1

Hi, I’,m trying to invalidate a refresh_token and its associated access_token with the ff. code

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 name="OA-InvalidateRefreshToken">
    <DisplayName>OA-InvalidateRefreshToken</DisplayName>
    <Operation>InvalidateToken</Operation>
    <Tokens>
        <Token type="refreshtoken" cascade="true">request.formparam.refresh_token</Token>
    </Tokens>
</OAuthV2>

However, I’m receiving an error of

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

I look at the policy, and it seems to be getting the refresh_token value properly, and second, I’m passing a valid refresh_token with an expired access_token. I don’t need it to validate whether if the access_token is valid or not as I am going to invalidate both of it anyway.

Is there any param like in

as seen in GetOAuthV2Info Policy?. So that I could successfuly invalidate both tokens?

2

yes

You are setting the “cascade” property on the operation to be true.

This will trigger the failure you have seen when the access token is expired. That seems like an unfortunate behavior, but that’s what it does. It seems to me that if you want to revoke a refresh token, and the access token is already expired, then the policy should gracefully proceed without error or fault. That would be minimally surprising and most helpful. But today that is not what happens.

If you set cascade=false, then it will work correctly as long as the refresh token is not expired. (It ignores the state of the associated access token in that case). In this case, you still have to deal with the possibly unexpired, and definitely not revoked access token. So a possible workaround is to invoke InvalidateToken operation with cascade=true first, with a faultrule that tries InvalidateToken with cascade=false. You may need to host those policies in a separate chained proxy for this to work in your scenario.

Your proposal to include an attribute like maybe “ignoreExpiry” is interesting. b/160325411
Today that does not exist, though.

What’s the specific user story or scenario, can you describe more?

1 Like
3

I thought the code snippet I have in the question would be the most direct way to validate a refresh_token and at the same time revoke both access_token and refresh_token using a refresh_token as identifier. As when I want to revoke/totally delete both tokens, but using access_token as identifier, I could just do this.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<DeleteOAuthV2Info name="OA-DeleteAccessToken" enabled="true" continueOnError="true">
    <AccessToken ref="request.queryparam.access_token"/>
    <DisplayName>OA-DeleteAccessToken</DisplayName>
</DeleteOAuthV2Info>

Odd, that I had to resort to using multiple policies and fault rules just to trigger this particular scenario. Hopefully there’s a more direct way really because as far as I know, tokens should be able to be revoked even when using refresh_token too as this is the standard in oauth as I was told by our lead developer.

In light of this policy behavior, I thought of refreshing the access_token and make it valid for a couple of seconds, for me to invalidate both access & refresh token, but it would just make me add another policy for this to be accomplished.

So, knowing that I could revoke both tokens using an access_token anyway, and I have to validate whether if the refresh_token is valid or not in our proxy anyway. I just had this

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GetOAuthV2Info async="false" continueOnError="false" enabled="true" name="GOA-GetRefreshTokenInfo">
    <DisplayName>GOA-GetRefreshTokenInfo</DisplayName>
    <RefreshToken ref="request.formparam.refresh_token"/>
</GetOAuthV2Info>

To check the validity of a refresh_token

& this

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<DeleteOAuthV2Info name="OA-DeleteAccessToken" enabled="true" continueOnError="true">
    <AccessToken ref="apigee.access_token"/>
    <DisplayName>OA-DeleteAccessToken</DisplayName>
</DeleteOAuthV2Info>

To invalidate both tokens using an access_token that was made available in the flow variable apigee.access_token when I had the GetOAuthV2Info in the earlier flow.

This would be a good workaround I guess.

4

I’m sorry you have to resort to such workarounds. I agree that Apigee should behave more robustly in this circumstance. I raised a defect on your behalf to change this behavior. The ticket number is: b/160325411

1 Like