invalidate refresh token does not throw error when passed an access token
using the edge oauth V2 policies, ive exposed the refresh token invalidation aka revocation functionality via rest api.
the problem is that when i pass this policy an access token instead of a refresh token, it does NOT throw an error, when it absolutely should throw an error. For instance, when i pass in a random alpha numeric string, it appropriately throws an error, so it is indeed verifying the validity of the token. However, it appears that the policy is inappropriately referencing both access and refresh tokens when it shuold only reference refresh tokens.
here is my Invalidate refresh token policy code. you'll notice ive specified the token as "refreshtoken" per the documentation specs. for some strange reason, this policy is not throwing an error when it receives an access token.
<OAuthV2 name="revoke-refresh-token">
<DisplayName>revoke-refresh-token</DisplayName>
<Operation>InvalidateToken</Operation>
<ExternalAuthorization>false</ExternalAuthorization>
<SupportedGrantTypes/>
<GenerateResponse enabled="true"/>
<Tokens>
<Token type="refreshtoken" cascade="true">request.foobar</Token>
</Tokens>
</OAuthV2>
Best Answer
the behavior is, if the Token type attribute is 'refreshtoken',
First we try to invalidate the refresh token, if the passed value is not the refresh token then we check if this could be a access token. If the passed value is a accesstoken, then the accesstoken is invalidated.
So, in your case I am expecting that the access token is also revoked? correct? that is also the reason why the policy throws errors for some invalid values and not for valid access tokens.
unfortunately, its not there in the document, will check on that - but can you confirm if you are seeing this behavior?
Also, can you pls tell us what is your usecase? maybe we could handle it differently
Thanks,
Mukundha,
Thank you for this explanation. Yes, I am seeing this behavior (access token is revoked).
My use case is simple and generic. Essentially, I want the user/client to be able to revoke their own token and/or refresh token as a way of "logging out" for security reasons. Do you need any more details?
I have noticed that once the refresh token is revoked, I can still pass the refresh token to the policy and it will revoke it again and again and again. It does not seem to realize that it's revoked. I've confirmed that the refresh token is invalidated because it is not accepted by the refresh token policy, but for some reason the invalidate does not treat the invalidated refresh token as invalidated. Any ideas here? I even passed a refresh token that was invalid for 12 hours and the policy still invalidated it as if it were not already invalidated. Strange behavior there, but not all that harmful. Misleading perhaps.
Thanks a lot, Mukundha!
Hi Chris,
Yes you are right. The policy does not throw errors for already invalidated refresh/access tokens. I will pass on this feedback to our engineers. Thank you for bringing this up
Thanks,
Hi Mukundha,
You're very welcome. I hope the details I've provided are enough for an investigation on the Apigee side. Thanks again for your help.
Best, Chris
The documentation at http://apigee.com/docs/api-services/content/validating-and-invalidating-access-tokens does state that passing an accesstoken, even if the type is "refreshtoken", causes revocation of the access token.
Hi Dino,
I had not noticed that, thanks for the tip. The bigger issue though is the fact that the policy does not throw an error if an invalid refresh token is passed. For example, passing a refresh token repeatedly will not cause any exceptions; however, you would expect to be able to only revoke a refresh token once, haha.
Just to beat a dead horse here, another example is that I'll pass a refresh token, it is successfully revoked. I go and try to refresh my access token / session with said refresh token, and of course it fails because it has been revoked. I go back to the revoke endpoint and pass it the invalidated refresh token, and it accepts the refresh token as still valid and will perform the invalidation operation again. This is definitely a bug, but definitely not a huge bug.
Yes, I understand the situation and agree that it's a bug. I'd prefer that the Revoke should throw a fault if given a revoked token. I'll file a report on that.
Something to consider is that when responding to the client you should not return an error if an invalid token is provided: From https://tools.ietf.org/html/rfc7009:
Note: invalid tokens do not cause an error response since the client cannot handle such an error in a reasonable way. Moreover, the purpose of the revocation request, invalidating the particular token, is already achieved.
I know this post is asking for more information from an internal call, which is a different beast. But something to consider nevertheless.
