We are using oauthV2 policy to validate the token with given scopes.
i.e.
clients hitting /api1/ should have scope api1
clients /api2/ hitting /api2/ should have scope api2 and so on
We are using flow variables
<Step> <Name>verifyOauthv2AccessToken-api1</Name> <Condition>(proxy.pathsuffix MatchesPath "/api1/**")</Condition> </Step> <Step> <Name>verifyOauthv2AccessToken-api2</Name> <Condition>(proxy.pathsuffix MatchesPath "/api2/**")</Condition> </Step>
Each verify policy we have scopes hardcoded like below
<OAuthV2name="ValidateOauthScopePolicy"> <Operation>VerifyAccessToken</Operation> <Scope>api1</Scope> </OAuthV2>
Question:
is it allowed to make the scope attribute dynamic? Setting it via javascript and using the variable in verifytoken policy scope attribute like
<OAuthV2name="ValidateOauthScopePolicy"> <Operation>VerifyAccessToken</Operation> <Scope>{custom.scopeapi1}</Scope> </OAuthV2>
I already tried this and it seems that its not working so wanted to check if I am missing anything or is it not allowed? It will help us to have only one policy instead of having multiple verify token policies for each service level scope.
Solved! Go to Solution.
For VerifyAccessToken policy, variables are not allowed for scope. This is mentioned in the documentation:
"If this element appears in a "VerifyAccessToken" policy, then it is used to specify which scopes the policy should enforce. In this type of policy, the value must be a "hard coded" scope name -- you can't use variables." @ http://docs.apigee.com/api-services/content/oauthv2-policy
For VerifyAccessToken policy, variables are not allowed for scope. This is mentioned in the documentation:
"If this element appears in a "VerifyAccessToken" policy, then it is used to specify which scopes the policy should enforce. In this type of policy, the value must be a "hard coded" scope name -- you can't use variables." @ http://docs.apigee.com/api-services/content/oauthv2-policy
Thanks @Sathish Balasubramaniyan for confirmation.
You may not need multiple "VerifyAccessToken" policies.
Remember: you can also use Condition elements in the proxy flow to check for the presence of scope, AFTER the VerifyAccessToken policy populates the context variables.
Thanks @Dino, thats a great option too.
@Dino - In our case, we are providing a shared component for token verification, and exposing as a standard to all our internal customers. That means Hardcoded scopes in VerifyAccessToken policy will not work for us. Is their any workaround for this use case ?
Are there any plans to make the scope element dynamic (with variables) in the VerifyAccessToken policy?
We have the same requirement as stated above: we would like to create a standard way of checking/creating tokens in a shared component. It would be handy if the scope element could be a variable.
I suggest that you ask new questions as a new question.