{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}

Google Cloud Apigee
1

Hi

In an oauth scenario I am working on I am getting the issue when the flow hits the Oauth2.0 policy.

"{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}

Spent several days trying to figure this out and reading all the community post that looked similar but without success.

Flow:

1. Shared Flow Callout: Verify JWT token.

  • Works fine, we dont have the JWT policies in our on prem install yet so we are using the old community version.

2. Oauth Policy: Generate token and associate details from JWT token to it.

  • It find the the client_id, can see it in the flow.

  • Works fine if I disable all the policies before it.

  • From documentation …by default the policy should look for the client id in the formparam x-www-form… , however since I had some issues I have added in the policy to be sure:

  • The proxy is connected to a products and my app.

<ClientId>request.formparam.client_id</ClientId>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-GenerateAccessToken-CG-MB">
    <DisplayName>OAuthV2-GenerateAccessToken-CG-MB</DisplayName>
    <Properties/>
    <Attributes/>
    <ExpiresIn>1200000</ExpiresIn>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <ReuseRefreshToken>true</ReuseRefreshToken>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
    <Tokens/>
    <GrantType>request.header.grant_type</GrantType>
    <AppEndUser>jwt_claim_upn</AppEndUser>
    <ClientId>request.formparam.client_id</ClientId>
    <Attributes>
        <Attribute name="grant_type" ref="request.header.grant_type" display="true"/>
        <Attribute name="jwt" ref="request.header.client_assertion" display="true"/>
        <Attribute name="claim_upn" ref="jwt_claim_upn" display="true"/>
    </Attributes>
</OAuthV2>

In some of the earlier posts that I found about this issue they tried to put back the client_id after the callout and before the Oauth policy, like this:

  1. Callout

  2. Assign Message: Take clientid from request and put back in the expected place

  3. Oauth policy

This did not make any difference for me and the policy finds the clientid in the correct place as I can confirm by looking in the flow.

At this time I am quite stuck and getting no response from support, so any help around this would be appriciated.

2

@Jerry Jönsson ,

You just need to send Authorization Header with base64encoded client id & secret. You don’t need to specifically mention ClientId in the generate token policy.

Have you tried that ?

3

Also, Make sure you set right headers x-www-form-urlencoded & send parameters using same.. See it in action here

4

base64: This looks to me like optional, for another project we are also taking them from the same place so should work, the difference is that we have a different kind of callout before the oauth policy in this case.

5

@Jerry Jönsson ,

Can you make sure “Content-Type” header is set to “application/x-www-form-urlencoded” , It’s not modified by callout ?

Also, Make sure you send the params as x-www-form-urlencoded instead of form-data ?

6

I can see that the content type is present when it reaches the Oauth policy, and the params is sent like this:

7130-param.png
7130-param.png663×200 5.34 KB

7131-param2.png
7131-param2.png932×594 29.2 KB

Hmm looking at this again now I am thinking that the issue could be that the shared flow is using Authorization header …and if that is present when hitting the Oauth policy, it will try to take the clientid from there?

7

“Hmm looking at this again now I am thinking that the issue could be that the shared flow is using Authorization header …and if that is present when hitting the Oauth policy, it will try to take the clientid from there?”

So turns out that if the authorization header is present then the oauth policy looks at that first…regardless if you specify that the clientid is somewhere else in the policy.

After I have removed the authorization header from the flow before the oauth policy hits using AM policy, it works. To me this seems flawed and not how I understood it from the documentation.

8

@Jerry Jönsson , Glad issue is resolved.

Agree, It’s confusing. Let me check with Engineering Team on this. @docs Team FYI..