{ Community }
  • Academy
  • Docs
  • Developers
  • Resources
    • Community Articles
    • Apigee on GitHub
    • Code Samples
    • Videos & eBooks
    • Accelerator Methodology
  • Support
  • Ask a Question
  • Spaces
    • Product Announcements
    • General
    • Edge/API Management
    • Developer Portal (Drupal-based)
    • Developer Portal (Integrated)
    • API Design
    • APIM on Istio
    • Extensions
    • Business of APIs
    • Academy/Certification
    • Adapter for Envoy
    • Analytics
    • Events
    • Hybrid
    • Integration (AWS, PCF, Etc.)
    • Microgateway
    • Monetization
    • Private Cloud Deployment
    • 日本語コミュニティ
    • Insights
    • IoT Apigee Link
    • BaaS/Usergrid
    • BaaS Transition/Migration
    • Apigee-127
    • New Customers
    • Topics
    • Questions
    • Articles
    • Ideas
    • Leaderboard
    • Badges
  • Log in
  • Sign up

Get answers, ideas, and support from the Apigee Community

  • Home /
  • Edge/API Management /
avatar image
1
Question by rj.walsh · Nov 02, 2015 at 06:23 PM · 1.6k Views oauth 2.0generate tokenclientidclient identifier

Client Identifier with OAuth External Authorization

I have the following OAuthv2.0 Generate Token Policy (which is attached to the response of the proxy endpoint flow because I get a JWT back from the target endpoint, I then validate&verify the JWT and i'm trying to now store it in an apigee token):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthGenerateToken">
    <DisplayName>OAuth.GenerateToken</DisplayName>
    <Attributes/>
    <ClientId>response.header.client_id</ClientId>
    <ExternalAccessToken>oauth.access_token</ExternalAccessToken>
    <ExternalAuthorization>true</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
    <GenerateResponse enabled="true">
        <Format>FORM_PARAM</Format>
    </GenerateResponse>
    <ReuseRefreshToken>false</ReuseRefreshToken>
    <StoreToken>true</StoreToken>
    <Tokens/>
</OAuthV2>

What I can't figure out is why this policy still generates this error:

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

In this case

response.header.client_id

is populated to a valid value (it shows up as being read in the trace), but it seems that policy isn't using the ClientId element to make the check that is associated with the error (I've tried with various other flow variables as well, none seem to work).

The only way I can get rid of the above error is to use this on the request flow and have the request be a x-www-form-urlencoded with a formparam named "client_id" (which has the same value that I have in "response.header.client_id now"). My understanding is that I can use the ClientId directive to override this default location, but so far I have been unsuccessful.

Any help is appreciated, Thanks!

Comment
Add comment
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

Close

4 Answers

  • Sort: 
avatar image
0
Best Answer

Answer by AMAR DEVEGOWDA · Mar 17, 2016 at 01:34 PM

@GuyH,

As informed to you over email, you need to do the following.

  • Have the AssignMessage policy "SetFormParamClientID" in the request flow (and not in response flow) because you have the set the request.formparam.client_id
  • You need to set the Consumer key associated with the DeveloperApp (corresponding to the Product associated with your API Proxy) and not the username (email id) as the grant_type is set as "client_credentials" in OAuthv2.0 policy "StoreToken"
  • In addition, you also need to set the grant_type in the AssignMessage policy "SetFormParamClientID".

This should help you to resolve the problem.

Regards,

Amar

Comment
Add comment Show 1 · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image AMAR DEVEGOWDA ♦ · Mar 18, 2016 at 09:32 AM 0
Link

@GuyH confirmed through email that it is working fine for him with the above suggestion.

avatar image
0

Answer by ozanseymen   · Nov 03, 2015 at 10:47 AM

It appears that you are right @rj.walsh. I am able to reproduce the behaviour. Apigee seems to be _only_ looking at request.formparam.client_id variable and nothing else.

As you probably already thought there is a terrible hack around this: use AssignMessage policy to set request.formparam.client_id to the value of response.header.client_id just before the OAuth policy in the response flow. This should enable you to use external authorization until this is fixed.

Comment
Add comment Show 4 · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image daniel.biales · Nov 28, 2018 at 08:24 PM 0
Link

@AMAR DEVEGOWDA or @ozanseymen has this been fixed or do we still have to use the hack. The downside is doing that clears out the entire request body and sets it to the client_id

avatar image Dino-at-Google ♦♦ daniel.biales   · Nov 28, 2018 at 10:14 PM 0
Link

I don't think anything has changed!

You do not need to set the request body.

The assignmessage looks like this:

<AssignMessage name='AM-FixupClientId'>
  <AssignVariable>
  <Name>request.formparam.client_id</Name>
  <Ref>response.header.client_id</Name>
  </AssignVariable>
</AssignMessage>

You're just setting one context variable.

avatar image daniel.biales Dino-at-Google ♦♦ · Nov 29, 2018 at 01:26 AM 0
Link

It looks like setting that context variable wipes out the request body. I've attached a picture from the trace.

screen-shot-2018-11-28-at-82542-pm.png (15.1 kB)
Show more comments
avatar image
0

Answer by GuyH · Mar 08, 2016 at 01:46 PM

Thanks for sharing, I was/am also stuck on this for an hour or two.

How did you get this to work?

As described, I added a AssignMessage policy as follows:

	<AssignMessage async="false" continueOnError="false" enabled="true" name="SetFormParamClientID">
    <DisplayName>SetFormParamClientID</DisplayName>
    <Properties/>
    <Set>
        <FormParams>
            <FormParam name="client_id">{apigee.username}</FormParam>
        </FormParams>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

But I still get the same error. I tried to both set the policies on the request and response flows, but that didn't matter.

Comment
Add comment · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image
0

Answer by naveen · Apr 14, 2016 at 04:17 AM

@GuyH

replace "{apigee.username}" with the clientId comming in the request.

Comment
Add comment · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

Follow this Question

Answers Answers and Comments

37 People are following this question.

avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image

Related Questions

OAuth v2.0:we have more than 30 attributes added to generate AccessToken.As per CPS we are not suppose to add more than 18 Attributes. 1 Answer

Pass client identifier to micro service 2 Answers

RefreshToken vs GenerateToken 1 Answer

Invalid Client Identifier when storing external token 2 Answers

Access Workday REST Endpoint from Apigee using OAuth2.0 1 Answer

  • Products
    • Edge - APIs
    • Insights - Big Data
    • Plans
  • Developers
    • Overview
    • Documentation
  • Resources
    • Overview
    • Blog
    • Apigee Institute
    • Academy
    • Documentation
  • Company
    • Overview
    • Press
    • Customers
    • Partners
    • Team
    • Events
    • Careers
    • Contact Us
  • Support
    • Support Overview
    • Documentation
    • Status
    • Edge Support Portal
    • Privacy Policy
    • Terms & Conditions
© 2021 Apigee Corp. All rights reserved. - Apigee Community Terms of Use - Powered by AnswerHub
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Create an article
  • Post an idea
  • Spaces
  • Product Announcements
  • General
  • Edge/API Management
  • Developer Portal (Drupal-based)
  • Developer Portal (Integrated)
  • API Design
  • APIM on Istio
  • Extensions
  • Business of APIs
  • Academy/Certification
  • Adapter for Envoy
  • Analytics
  • Events
  • Hybrid
  • Integration (AWS, PCF, Etc.)
  • Microgateway
  • Monetization
  • Private Cloud Deployment
  • 日本語コミュニティ
  • Insights
  • IoT Apigee Link
  • BaaS/Usergrid
  • BaaS Transition/Migration
  • Apigee-127
  • New Customers
  • Explore
  • Topics
  • Questions
  • Articles
  • Ideas
  • Badges