Jwt token setting

[xavierlopez85]

I'm trying to connect to our public API, which requires a JWT token.

First, I created an object for the Web API Service (POST Auth action/API JWT), which has one POST method where I pass my credentials to obtain a JWT token.

Next, I created another object for the Web API Service (API SERVICE )with a single GET action using Bearer Token authentication. However, I haven't found a way to pass the token I obtained to the authentication settings automatically.

As a non-ideal workaround, I created a credential variable and used it in the Bearer Token authentication settings (this works), but it requires me to manually call the POST Auth action and update the variable every 20 minutes.

As a second workaround, I created an HTTP request action (GET), and in the header, I'm appending the token I received. ( it works )  

I'm just trying to get it working as a Web API Service object so the rest of the team can use the actions without manual updates.

The other issue I’m not sure how to handle is that the token expires after 20 minutes.

By the way, I'm pretty new to these cool technologies, so thanks in advance for your help!

I'm using Robotic Process Automation Software v7.1.2

[david.l.morris · Accepted solution]

If there is any functionality in Blue Prism to handle re-authenticating periodically automatically, I'm not aware of it. There are two ways that I have handled this. Which one is better for you I can't say. But I suspect the 2nd option would be best due to having such a low expiry time.

1 - The way we handle this is to have a Token Refresher process that runs every x minutes. This process simply calls any Authenticate actions we have across any objects (whether that's a VBO or Web API). I usually like to make Authenticate actions in a VBO so that I can add extra logic as needed, such as performing whatever extra logic I want in terms of storing the returned JWT token in a credential that is of type Bearer Token like you said. And just as you described, your other Web API can use that bearer token credential as its common authentication.

2 - Another way I like to do when the timing of authentication isn't predictable or if it needs to constantly reauthenticate and it is very often: Instead of having a Token Refresher process that runs every x minutes, instead you implement logic either in each automation/process to authenticate first OR put a subpage reference or action call as the first step in every action. This just depends on how much control you have over different pieces. In some way though, the goal here would be for a check to be performed upon each API call to determine whether your token is still valid or not. If it is no longer valid (expired), then it re-authenticates and stores the token again back into the credential. I know that JWT tokens technically have their expiry information inside the token itself, but what I do instead is just store the expected expiry datetime in a credential (I commonly used a Credential Property to hold the datetime text and I cast it to DateTime when reading it back in). Doing it this way, as long as your logic is good, then you can pretty much just forget about it, and the logic will just handle re-authenticating whenever it is needed.

Some things to consider. Some APIs will actually invalidate previously-generated tokens for the same user ID when authenticate happens to generate a new token. Some, however, will actually allow you to generate hundreds of different valid tokens. If your API is one of these (example is CyberArk) that allows multiple valid tokens at the same time for the same user, then you could just have different credentials for each automation such that each automation has its own JWT token at any given time and in that case you can just have the automation authenticate when it starts and then renew its own token whenever is needed. I must say 20 minutes is a very aggressive timeframe for token expiry. In the 20 or 30 different APIs I've worked with, I've never seen such a low expiry time. I would personally complain about that in case it is simply due to an over-ambitious developer/owner of that API.

[xavierlopez85]

Ei David! thanks for your reply, as a side comment your 4 h video on how to call Api's was very helpful. 

So, I'm going this way (option 2)     validating if the token is alive before trying to obtain a new one.

Even though, I can actually generate hundreds of different valid tokens with my same credentials, for the current project we will have to loop or create a queue ( nor sure yet )  over 1000 records, so creating that amount to jwt's  I think might be inappropriate .. Good thing and bad thing is that the jwt ttl ( time to live ) is setup to 15 min hahaha (security issues) , so calculating if is still a valid token looks like the best approach for this specific scenario.