How to specify an alternative token location for VerifyAccessToken

[DChiesa]

The doc for VerifyAccessToken says that the policy retrieves the token from the standard loction for OAuth bearer tokens, which is to say, within the Authorization header.

The doc also says that it is possible to configure a different source location for the token value, using the Accesstoken element:

<OAuthV2 name="Verify-OAuth-1">
  <Operation>VerifyAccessToken</Operation>
  <AccessToken>variable_containing_token_here</AccessToken>
</OAuthV2>

I tried using this and could not get it to work as expected. I repeatedly got "invalid access token", even though my context variable did contain a valid token.

In my case, the inbound request DOES have an Authorization header, but that header does not contain a valid token known to Apigee Edge. Is it required that I must remove this header in order to get the policy to recognize the context variable that does contain the token?

[willwitman]

Hi @Dino,

I've tried reproducing this several times and it seems to work for me. Here is my policy:

<OAuthV2 async="false" continueOnError="false" enabled="true" name="verify-token">
    <Operation>VerifyAccessToken</Operation>
    <AccessToken>request.queryparam.access_token</AccessToken>
    <GenerateResponse enabled="true"/>
    <Tokens/>
</OAuthV2>

And here's an example of a request I sent that has both the query param with valid auth token (which is what the policy is looking for) and an Authorization header that has a value set that is totally unrelated to the OAuth. If I remove the auth header, it doesn't make any difference. The policy validates the token.

GET /refresh-token/verify?access_token=LuWRQrlfkniEzSvATpPj9qhL7OJ HTTP/1.1
Host: wwitman-test.apigee.net
Authorization: Basic <long random string>
Cache-Control: no-cache
Postman-Token: 11ca19eb-0d6f-6aa5-4d81-99670d062eeb

Not sure what's going on. Does your token work if you just use it in the auth header and remove the AccessToken element?

[#3]

Hi @Dino,

Were you able to figure out a solution for this? I'm facing the same issue.

Thanks,

Abi

[ssvaidyanathan]

What is the error you see ? can you share your curl command and the trace details ?

[robinm · Accepted solution]

I recently stumbled across this again.

According to the doc for accesstokenelement the answer from @Will Witman is correct in that an alternate location only works as a queryparam, not as any other header, sadly.

If presented in the header, it must be an Authorization header and be sent as a Bearer token.