Apigee X Create custom OAuthV2 access_token

[donutquan]

I am relatively new to Apigee and want to use the "apigee.access_token" generated by Apigee and append it to one of my existing variables called "tokenPayLoad". After that, I want to use this newly formed access_token for future calls to my API.

I have tried using SetOAuthV2Info policy but it still does not work as subsequent calls requiring access_token still check with the originally generated access_token.

<ProxyEndpoint name="token">
...
<Flow name="token">
    <Request>
       <Step>
          <Name>Token-BuildRequest</Name>
       </Step>
    </Request>
    <Response>
       <Step>
          <Name>GenerateAccessToken</Name>
       </Step>
       <Step>
          <Name>Token-BuildResponse</Name>
       </Step>
       <Step>
          <Name>AM-TokenResponse</Name>
       </Step>
    </Response>
</Flow>
...
<ProxyEndpoint name="verification">
...
<Flow name="verify">
    <Request>
        <Step>
            <Name>OAuthv2Verify</Name>
        </Step>
        <Step>
            <Name>RF-InvalidToken</Name>
            <Condition>error.status.code = "401"</Condition>
        </Step>
    </Request>
</Flow>

GenerateAccessToken

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="GenerateAccessToken">
    <DisplayName>GenerateAccessToken</DisplayName>
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>900000</ExpiresIn>
    <Algorithm>RS512</Algorithm>
    <GenerateResponse enabled="true"/>
    <Scope>scope</Scope>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <GrantType>grant_type</GrantType>
    <TokenType>Bearer</TokenType>
    <TokenLength>6000</TokenLength>
    </Attributes>
</OAuthV2>

TokenBuildResponse.js

var tokenPayLoad = JSON.parse(context.getVariable('tokenResponsePayload'));
const accessToken = context.getVariable('apigee.access_token');
tokenPayLoad.access_token = tokenPayLoad.access_token + "." + accessToken
context.setVariable('response.content', JSON.stringify(tokenPayLoad));

OAuth2Verify

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthv2Verify">
    <DisplayName>OAuthv2Verify</DisplayName>
    <Operation>VerifyAccessToken</Operation>
    <Scope>TestApp</Scope>
    <SupportedGrantTypes/>
    <GenerateResponse enabled="true"/>
    <Tokens/>
</OAuthV2>

[dchiesa1]

---

@donutquan wrote:

want to use the "apigee.access_token" generated by Apigee and append it to one of my existing variables called "tokenPayLoad". After that, I want to use this newly formed access_token for future calls to my API.

---

why? what problem are you trying to solve? What if you sent back to the client ... just the access token, which is the tyopical case, the thing 99.96% of Apigee users does?  What is unsatisfactory about that approach?  Why do you want to do something different? If you explain more I might be able to help you.

I don't quite understand "append it to one of my existing variables". Don't understand why you'd want to do that.

---

@donutquan wrote:

I have tried using SetOAuthV2Info policy but it still does not work as subsequent calls requiring access_token still check with the originally generated access_token.

---

I believe that policy sets information stored with an existing token. It does not "modify" a token, but sets attributes that APigee stores with a token. So I don't think it will do what you imagine it to do... "append the token to" an existing variable.

BTW in the OAuthV2 policy, if you use Operation=GenerateAccessToken , then you should not  use Algorithm.  The Algorithm is used for when you use the policy to issue JWT -format tokens.  That requires Operation=GenerateJWTAccessToken. But that seems to be irrelevant to the main thing you're doing, which is... some sort of custom formatted token. (Which, as I said, I don't understand the motivation for) 

[donutquan]

Hi @dchiesa1, it is part of an authentication approach I am attempting. I have a variable (tokenPayLoad.access_token) which contains a token from another endpoint (let's call it Gateway X) and I want to append a newly generated token

I want to create an oAuth2 token in the following format: tokenPayLoad.access_token + "." + newly generated token. Thereafter, I will use this token for my OAuthv2Verify.

[dchiesa1 · Accepted solution]

i wouldn't do it that way.  If you have a token from some other gateway, and you want to be able to access it from within Apigee, one good way to do that would be to attach that external piece of data as a "custom attribute" to a token that Apigee generates. In Apigee, custom attributes are metadata that you can associate to a variety of entities - like Apps, developers, products, or tokens.  Each attribute is a name/value pair. 

For custom attrs on tokens, you can set them at the time of issuance - within OAuthV2/GenerateAccessToken , using the Attributes element.  Or, you can append custom attributes to tokens, AFTER they have been issued, with the SetOAuthV2Info policy. 

In either case, the client app has the Apigee-issued token. When it presents the Apigee-issued token in a request-for-service, the Apigee proxy can verify the token, and that will implicitly load into message context, the values of the custom attribute.  In this case, the external token .

Doing it this way means you don't resort to "concatenating tokens" or some other "manual" token wrangling approach. 

Would that solve your case? 

What does Apigee DO with the token from Gateway X? 

I am imagining this. kind of flow:  a client connects to Gateway X and gets a token for Gateway X.  Then the same client connects with Apigee, and presents credentials for Apigee, along with the token for Gateway X.  Apigee issues a token, attaching the Gateway X token as an attribute. On subsequent request the client can send the Apigee-generated token into Apigee. Apigee can verify it.  Then implicitly retrieve the GaterwayX token, and then use that token to make calls to Gateway X, on behalf of the client. 

Is that kind of what's you're imagining? 

[donutquan]

Yes, that is what I am imagining. I think this will be a viable approach to solving my case. Thank you for taking the time to explain and offer substantial information on how I can resolve my question.