I have a GenerateAccessToken OAuthV2 policy configured as follows
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <OAuthV2 name="OAuthV2.GenerateAccessToken" continueOnError="false"> <Operation>GenerateAccessToken</Operation> <Scope>request.formparam.scope</Scope> <ExpiresIn>1200000</ExpiresIn> <SupportedGrantTypes> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <GenerateResponse enabled="false"/> </OAuthV2>
When I send the following request
curl -v -X POST -d 'grant_type=client_credentials' https://myorg.apigee.net/v1/oauth/token
The request fails as expected (because the client_id and client_credentials are not present), and I see in trace that the policy fails, and the fault that is raised (InvalidClientIdentifier)
But when I send this other request
curl -v -X POST -d 'grant_type=password' https://myorg.apigee.net/v1/oauth/token
My expectation would have been that the policy also fails, with fault UnsupportedGrantType, but it simply does not fail, an continues execution.
However, if I change GenerateResponse to true it generates a 400 Error response with the following payload
{"ErrorCode" : "invalid_request", "Error" :"Unsupported grant type : password"}
I think that the policy should be consistent in its behaviour and if I have set GenerateResponse to false and there is a fault, because the grant_type is not supported, it should actually raise it, like in the InvalidClientIdentifier case.
Any ideas why the policy does not raise the fault in this particular case?
Thanks for bringing this up -- your explanation is clear and it was easy to reproduce. I have a feeling this is a bug in the policy. I don't think it's an undocumented special case of some kind.
I think with your configuration the OAuth2 policy should throw a runtime error, enter the error flow, and populate the appropriate error variables. But as you pointed out, it doesn't do that.
This makes it difficult to trap the error in a fault rule to return a custom error message, for example. I'll raise a bug and see if it can be addressed either with better explanation or by fixing the code (if it is a bug) and report back.
@wwitman Thanks, I already opened a bug report last week.
Is there any update to above issue?
Here's the update.
This problem is still present in the GenerateAccessToken behavior.
The reference number on this is b/67167849 .
User | Count |
---|---|
7 | |
2 | |
2 | |
2 | |
1 |