I have to use bearer tokens which expire after one hour. It is a requirement to make a new JWT and get a new access token. This is because of two claims and their relationship to the epoch. Can NR be configured to let the system know when it’s make a new JWT and get a new bearer token?
The token expiry timestamp is generally included in the JWT data so as long as you can make sense of that, you could pass the information into a function node which creates a setTimeout
function with the correct number of ms It would send a msg on timeout expiry which you could use in a dedicated flow to renew the JWT.
Incidentally, JWT's should be short-lived because they are prone to hijack attacks.
Are you asking for an API youve created in Node-RED or is this about the admin API and adminAuth?
If the latter, I've been looking at this recently for what what we're doing at FlowForge and came to conclusion that it needs improving. The whole area of session expiry/refresh is doable, but it does feel like the API could be more helpful. But I don't have a clear sense of what the API needs to exposes to enable this properly.
If this is about adminAuth then it would be great to have a chat to understand exactly how you're using the API today and what you need to do.
This is for an API created by a commercial EHR vendor. One that controls 54% of all medical records in the USA:
I can build the jwt, post to get a bearer token, and use it to scrape records out of the EHR. This works fine for 60 mins,
{
"iss": "d45049c3-3441-40ef-ab4d-b9cd86a17225",
"sub": "d45049c3-3441-40ef-ab4d-b9cd86a17225",
"aud": "https://fhir.epic.com/interconnect-fhir-oauth/oauth2/token",
"jti": "f9eaafba-2e49-11ea-8880-5ce0c5aee679",
"exp": 1583524402,
"nbf": 1583524102,
"iat": 1583524102
}
iat and exp are the issues that need a timer function. They have to be re-calculated each time. No reuse. The rules for these are:
iat: Time integer for when the JWT was created, expressed in seconds since the "Epoch" (1970-01-01T00:00:00Z UTC). The **iat** value cannot be in the future, and the exp - iat difference cannot be greater than 5 minutes.
exp: The exp value must be in the future, and can be no more than 5 minutes in the future at the time the access token request is received.
jti: if exp and iat were not enough to give you a headache then toss in jti. The jti must be no longer than 151 characters and cannot be reused during the JWT's validity period, i.e. before the exp time is reached. Very specific GUID
"dedicated flow to renew the JWT." - technically not renewing a jwt. Have to make a new one, with new exp and iat claims based on this moment in time. I have a function that builds a jwt, just need a way to know when to start it, and how to stuff the bearer token back into the flow. Right now its a manual process. The next EHR has an expiration policy of 5 mins,not 60 mins.
Are you sure? Do you know how to sign the JWT? That is done by the server typically. Otherwise anyone would be able to create a JWT.
This is what I have to do, and it works. My public key is on their server. I sign with my private key. Like the following:
The header and payload are then base64 URL encoded, combined with a period separating them, and cryptographically signed using the private key to generate a signature. Conceptually:
signature = RSA-SHA384(base64urlEncoding(header) + '.' + base64urlEncoding(payload), privatekey)
The full JWT is constructed by combining the header, body and signature as follows:
base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.