Manage Token provide by Back end API using JWT

[#1]

Hi,

I am consuming the back end (target) API which implement JWT security mechanism. Every time when I call back end API, have to pass JWT Token or other parameters to access the back end API..

My approach :

step 1. Use the Service Callout policy and call the back end API which in response return Access token.

Step2. Store the obtained token in Step1 in a variable.

Step3. Call the back end API with setting or passing the parameters obtained in the Step2.

Is this approach right?

I have seen many place it is mention to use Java Callout policy.

Can you please share any sample related to mu use case?

Your comments is very valuable, please provide your suggestion.

[DChiesa]

mmmmm, I'm not entirely clear on what's happening here.

But, yes, if you need to call a backend system that requires a token, one approach is as you describe:

1. Check the cache for a viable token - this will use LookupCache
2. if there is no cached token, use ServiceCallout to acquire a cached token, and store it in the cache. This will probably use the ExtractVariables and PopulateCache policies, each wrapped in a Condition.
3. Use the token to invoke the target. This will probably involve AssignMessage to set a header or other parameter.

You said "I have to pass JWT Token or other parameters".

Or? So, you have an option to use JWT or ... something else? what is the something else? What generates the JWT? Who signs it? Which system holds the signing key?

Could you identify the target system so we can understand the security requirements better? Is it publicly documented?

[#3]

Thanks Dino for your prompt reply.

The back end external system expose the public API which generate the JWT token which need to pass when calling others back end APIS.

Everything related to security (like generate token and manage it etc.)manage by back end external system, we are the consumer of the API.

I understand the first approach but also thinking for 2nd approach.

My 2nd approach is:

A) Get the token and store in the Apigee - in the same way as did for - "using 3rd party External token" . The details available here -

https://docs.apigee.com/api-services/content/use-third-party-oauth-system

B) Now onwards call to other back end APIs use this token.

My query is :

Is JWT policy provide something to store external generated token in the Apigee? My understanding is JWT policy use to generate the token - in the same way as OAuthv2 or it's related policy does. JWT policy not for storing the external token, am I right?

The advantage of 1st approach (not store the external token) is :

• Every time get the latest token and use it . No need to refresh or manage token at our end. Everything happen in just one call, otherwise every time make 2 calls - first for get token and second to call actual API which need token.
• Easy for consumer of our API - no hassle to first make call to get token and then use it.
• Use the same security provide by external back end system

Drawback:

• Getting token and use it - process is hidden (getting token and using it happen in one call).

The advantage of 2nd approach (string external token in Apigee)

• Token available in Apigee platform

Drawback:

• Make 2 calls - one for getting token and second for actual API call by passing token
• Extra implementation - storing implementation
• Responsibility to manage the token.
• Exactly not the same as back end - make changes in the Apigee related to security

I think approach 1st is good - because not making any change at our Apigee end and using the back end external system as provide by back end team.

Please provide your comments on my understanding. Sorry for long details but it is important to explain you clearly.

Thanks

Raj