Authorize a request by comparing a token attribute with a request attribute

[#1]

We currently have an OAuth token being passed as an `Authorization` header, and the token has a custom attribute called `userId`. In addition, a `userId` header is being sent with the same client request. We'd like to authorize the request by comparing the two values, but are falling short on our attempts.

Currently we have an `OAuthV2` policy as a step in our preflow, and while performing a trace, we see the custom `userId` attribute as a variable in the scope of the policy. However, we haven't figured out how to extract that value to a variable that will be in scope in a subsequent step. The value only seems to be in scope during the execution of that step.

We'd like to avoid performing this authorization on our backend service. Any help is much appreciated!

[akoo]

Hello @Chris Ramacciotti,

After verifyaccesstoken operation in OAuth V2 policy, try using the following variable

accesstoken.userId

For a list of other variables populated during verification, please see the OAuth v2 info page here.

[DChiesa]

And just some other information Chris...

we see the custom `userId` attribute as a variable in the scope of the policy. However, we haven't figured out how to extract that value to a variable that will be in scope in a subsequent step.

When you say "we see...", I suppose you are referring to the Trace UI. The Trace UI in the Apigee Edge web ui will show you variables that are READ or WRITTEN during each step in the flow. If a step neither reads nor writes a particular value, then the trace ui will not display that variable, but be assured that the variable that was written in a previous step (a variable like accesstoken.userId) is still available and *could be* read in subsequent steps.

Finally, if you want to compare, then in a step directly after VerifyAccessToken, you can include a condition like this:

<Flow name='Chris-1'>
  <Request> 
    <Step><Name>VerifyAccessToken</Name></Step>
    <Step>
      <Condition>NOT (request.header.userid = accesstoken.userId)</Condition>
      <Name>RaiseFault-UserIdMismatch</Name>
    </Step>
    ...

does that make sense??