VerifyAccessToken error code handling

Not applicable

Hi, I need some tips or ways to properly handle error codes thrown by VerifyAccessToken Policy. Please see attached screenshots.

I want to handle them on Fault Rules like this: fault.name == InvalidAPIKey

But can't seem to find the right name for this type of error codes.

screenshot-from-2016-03-10-104913.png

screenshot-from-2016-03-10-104858.png

0 14 1,171
14 REPLIES 14

Not applicable

I have seen yet another type of invalid access token. How do I handle these now ? screenshot-from-2016-03-10-110122.png

adas
Participant V

@Hanzel Garcia I am attaching this sample bundle. It demonstrates couple of error handling cases for invalid token and expired token. See if this helps. You should specifically look at the below code snippet:

    <FaultRules>
        <FaultRule name="InvalidToken">
            <Step>
                <Name>FaultInvalidToken</Name>
            </Step>
            <Condition>fault.name = "invalid_access_token"</Condition>
        </FaultRule>
        <FaultRule name="ExpiredToken">
            <Step>
                <Name>ExpiredAccessToken</Name>
            </Step>
            <Condition>fault.name = "access_token_expired"</Condition>
        </FaultRule>
    </FaultRules>

What I am doing here is very simple. If the token is invalid, I throw a 401 error whereas if the token is expired I send a 302 redirect to the refresh token endpoint with the refresh token so that the client can generate a new token. Hope this helps.apigee-payment-rev19-2016-03-10.zip

Hi @arghya das, I will try this and will get you feedback as soon as it is applied.

@arghya das

Hello, I tried the given solution. It works fine. However, the CORS isn't working when these faults are called. Do we need to make any changes for CORS to work when these faults are called?

@Shivakumar Sudi - This is the expected behavior as errors exit the normal flows and errors are handled by faultrules if any are defined. So you will need a CORS definition in the faultrules as well

Its a similar answer as mentioned in this post -

https://community.apigee.com/questions/65987/cors-not-working-for-access-token-expired-error.html

@arghya das I have that already in my proxy, but somehow it's not being used. It works if I don't catch the default expiry fault to raise a different fault.

CORS is working now. Below is the working snippet.

<FaultRules>
<FaultRule name="InvalidToken">
<Step>
<Name>add-cors</Name>
</Step>
<Step>
<Name>FaultInvalidToken</Name>
</Step>
<Condition>fault.name = "invalid_access_token"</Condition>
</FaultRule>
<FaultRule name="ExpiredToken">
<Step>
<Name>add-cors</Name>
</Step>
<Step>
<Name>ExpiredAccessToken</Name>
</Step>
<Condition>fault.name = "access_token_expired"</Condition>
</FaultRule>

@Shivakumar Sudi - Seems you are adding the CORS policy in each faultrule. Instead add it in default faultrule and set alwaysenforce to true. That way, it will help you handle the CORS headers for all the faults; unless you have a requirement to send the CORS for only a selected set of faults

@Nagashree B I have customized errors for expiry token and invalid token, so to raise those faults, I have added CORS policy in each fault rule.

Not applicable

Hi @Hanzel Garcia, I see a variety of "fault.name"s for Verify Access Token policy.

Here is my list of fault.name values that you should handle (at least).

invalid_access_token

InvalidAccessToken

InsufficientScope

AccessTokenExpired

            <Step>
                <Name>InvalidAccessTokenError</Name>
                <Condition>(fault.name="invalid_access_token" or fault.name="InvalidAccessToken" or fault.name="InsufficientScope" or fault.name="AccessTokenExpired")</Condition>
            </Step>


Not applicable

@arghya das

@docs
Looking at previous responses and based on my experience I see that their are some faults (likeAccessTokenExpired, InvalidAccessToken, access_token_expired -- seems important ones and developers should be aware of these), which are not mentioned either on OAuth policy documentation or on common error code reference page.

Are there many more such faults which are really important when it comes to fault handling?

Also I did not get the point of having two different faults for invalid access token ( InvalidAccessToken, invalid_access_token ) and for expired access token ( AccessTokenExpired, access_token_expired).

@Vipul Agarwal -- Great feedback. I'll make sure the docs reflect all the error codes and that they are organized more effectively -- we've been actively updating error docs for all the policies. I did notice that AccessTokenExpired is the only one listed above that does not seem to be in the docs, although it is confusing to have to look in two places for these codes. Also, I believe that (for VerifyAccessToken) you can trigger InvalidAccessToken if you omit the auth header entirely, while invalid_access_token is triggered when you do pass an auth header, but give an invalid token or omit the token. I'm not sure yet about the pair of "token expired" codes, but will be sure to clear it up.

Thanks,

Will

@wwitman Thanks for the quick response. One more feedback is that the inconsistency in fault name patterns is not very pleasing. Some faults are in lower case (underscore separated), some are with FirstLetterCaps. I am not sure if it is for a reason but it would have been better if we follow the consistency in error codes / fault names.

I agree with you about the inconsistent name patterns for errors, @Vipul Agarwal. Your comments are much appreciated.