Integration Server handling JWT third party (consumer service)

, , ,
#1

I want to know the best practice/approach and how to handle case below,
Integration Server consume the third party services and those service are protected by jwt. This implementation require in the integration server instead of APIGW.
I need to get JWT token by calling the vendor login resource passing username and password only incase token expired. In next business service call will pass the that token in request header.

Where to store username and password and how to get this for generating the token?
Where to store the above token and how to validate token expiry is valid or not before to call next business service call?

Thanks

#2

How secure is your server? Can you store creds in global variable thru webMethods Admin console?

JWT can be decoded to find expiration time (if you have JWT generated, use https://jwt.io/ - its debugger page can be used to view content of token (you can also write a program to decode). After all - all oauth2 tokens are jwt tokens as well.

Simplest way is to write a service that generates token and use service caching technique - that way you can use same token without any additional programming (and if you expire service results before token expires you don’t have to check validity of token). Having said that - tokens put in ehcache (programmatically or thru service caching) can be accessed by other services running on IS (the tokens are stored in memory as plain text).

If you want the service to be more reliable, you should build a retry (hopefully service you are trying to invoke is idempotent. Fun fact @Theodore_Ezell1 taught me that word in 2005) - that way in case token was “revoked” at issuer - you could handle it (In this scenario, caching will be your enemy - as you would need to expunge previous token from cache).

if you are more adventurous - you could write a cloudstream connector.

Hopefully - someone has a better answer. :slight_smile:

1 Like
#3

Hi @CHIRAG, I really thankful to you for the guidance. Regarding fist concern, yes I’m planning to store as password global variable. But I don’t know the disadvantage/harm if I store in global variables.

I see the challenges here what you explain above.
First challenge is to write a program to decode the token for expiry.
Secondly, Store this token in memory either by program or service cache is ok for constant expiry value like 15 min. But if the token expiry change/revoke then need to handle the token cache refresh.
Thirdly, As token is store in memory in clear form it is security risk for financial transaction.

I am searching the IS built in service or other good design to handle this case.

What is your advice/concern if we use the APIGW to handle this token and pass in the next service call? Is it handle by configuration only or need a service development here? I know my new queries is contradict my main topic. But I’m searching the best design and approach.

#4

Hi Zeeshan,

Global Variable substitution is only for the Static key-pair value , Also if you don’t have any concern in storing your password in readable format then no issue ( Finance related application its not allowed to store the password as global variable even though your IS server is secured ].

Store your password in encrypt format in config file or in db. During the package load ,write a service to read and decrypt and configure as startup service and store it in cache as key pair value.

1 Like
#5

Thanks your suggestion.

#6

Yes store it in encrypted format (secured properties file) is the GO option and this will eliminate any security risk and for Ops team.

HTH,
RMG

#7

To reiterate @rmg,
please use Is Password to store it securely.

Irrespective of how it is stored on file system - in memory at some point, it is going to be decrypted.

image

#8

While I have not used API Gateway; say API gateway handles token - at that point, it is just matter of trust; i mean API gateway trusts IS, and external app trusts token from API gateway.