oauthV2.failed is true but not raising a fault - Verify API Key and Secret with Refresh Token Request

We have a proxy that verifies API Key and Secret before passing to an external IDP for an access token. The first OAUTH policy works fine to validate the client if the call is specific to just getting an access token. However, the first OAUTH policy fails (oauthV2.failed is true) and does not raise a fault when seeking a refresh token. It appears to act like a pass through and sends to the external IDP.

Our configuration is based on this use case: https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-validate-key-secret

When the refresh_token request is sent, it is sent with a form parameter grant_type of refresh_token along with the appropriate Basic Authorization header.

Is this the expected OAUTHV2 behavior for refresh token? It should act like a pass through?

Here's my policy specific to refresh:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OA-verifyAPIKey-and-Secret-Refresh">
    <DisplayName>OA-verifyAPIKey-and-Secret-Refresh</DisplayName>
    <Properties/>
    <Attributes/>
    <ExternalAuthorization>false</ExternalAuthorization>
    <StoreToken>false</StoreToken>
    <Operation>GenerateAccessToken</Operation>
    <SupportedGrantTypes>
        <GrantType>password</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="false"/>
    <GenerateErrorResponse enabled="true"/>
    <Tokens/>
</OAuthV2>
2 6 534
6 REPLIES 6

So, if oauthV2.failed=true, why isn't it raising a fault? That doesn't make any sense.

I guess you could do a condition check w/in an additional step and raise a fault if oauthV2.failed=true but that feels like a work around.

Exactly. Why isn't the OAUTHV2 policy validating key/secret properly on the refresh_token grant_type? I need to validate prior to sending to the external IDP.

Well I found a workaround to get the OAUTHV2 policy to actually validate the key/secret for the refresh_token.

1: Added an Assign Message policy to add in three fake values: two form parameters (username=username and password=password) and header (grant_type=password)

2: Adjust the OAUTHV2 policy to recognize those fake values:

<GrantType>request.header.grant_type</GrantType> <UserName>request.formparam.username</UserName> <PassWord>request.formparam.password</PassWord>

3: Added an Assign Message policy to remove the three fake values

Essentially you have to provide something for these three values in order to get the policy to run correctly. This "trick" does not fall in line with: https://tools.ietf.org/html/rfc6749#page-47

I think this is a bug with the OAUTHV2 policy???

This may be a bug.

do you have a support contract? If so I'd advise raising a support ticket, providing a simple proxy that can be used for reproduction, and asking the Apigee support staff to investigate. Or maybe you could be more specific about what the proxy is doing. What other policies are you using? What do the different inbound requests look like, specifically? And for each case, What results do you expect to see, specifically? and how does that differ from what you are actually seeing?

Normally I'd look into something like this but I'm not available at the moment.

I am not clear whatthis means:

However, the first OAUTH policy fails (oauthV2.failed is true) and does not raise a fault when seeking a refresh token.

It seems like you expect the policy to raise a fault. if so, Can you be more clear about why?

Are you saying that you're passing incorrect credentials and with those incorrect creds you're expecting to see the policy fail (and throw a fault)?

It appears to act like a pass through and sends to the external IDP.

The OAuthV2 policy doesn't pass through credentials to an external IDP. With Apigee, You would need to construct a proxy to do that explicitly.

This is why a simple reproduction case will be helpful.

lb-bug-demo-oauth-idp-rev8-2020-01-03.zip

apigee-bug-idp-demo-copypostman-collectionjson.txt

Dino: I created a stripped down sample proxy so you can see what I mean. For the refreshToken flow portion, do the following: test with the original refresh OAUTHV2 policy to see how it will not validate the client key/secret; then, comment that step out and uncomment the preceeding three steps that incorporate my workaround. Now it will validate client key/secret for the refresh token behavior. What you'll see is that the delivered policy does not process refresh_token grant_type as per RFC 6749 without assistance.

A sample postman collection is also included. Remove ".txt" and format back to ".json" to upload the collection correctly.

The original proxy is built using this use case as guidance: https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-validate-key-secret

However, the use case does not cover refresh token behavior.

Please let me know if you need additional info. Also, we do have a support contract.

Thank you

I created the following support case in the meantime:

1476085