Hi all,
I've been trying to find a concrete answer to this but haven't yet. One of our clients is intending to make some data actions that are using JWT as a Bearer token. This would be done via Web Services Data Actions integration.
For example, the Authorization header would look like this:
"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c" (example JWT found online)
Would this work? If not, are there any alternatives other than building out a middleware?
Regards,
We developed a couple of integrations for Google and Adobe that utilize JWT. After seeing how every JWT authentication scheme was different we put implementing "generic JWT support" on hold.
Is there public documentation for the endpoint they wish to utilize?
Are they expecting to generate a new JWT token for every request, or would they generate one and use it for a while until it expires? If they are expecting to use a token for a while then they would use the " User Defined (OAuth)" credential type and custom auth action.
If this endpoint requires more than what data actions can natively handle, we do support data actions calling AWS lambdas or Google Functions as your middleware.
Hi Jason,
Thank you for the info.
These API requests would be performed from Architect using data actions, so we would generate one JWT token per interaction (most likely). No public documentation on this particular implementation is available for now (we're still waiting on the client to provide all the details)
To clarify, we wont be parsing the JWT itself, the idea is simply to obtain it via one data action, and then use it as a Bearer token in all the following data actions. Can data actions handle sending a header formatted like in my initial post? ("Bearer xxxx.yyyyy.zzzz") If data actions can handle that, i see no other problems.
We can definitely support sending "Bearer whatever-long-string-you-need" in an auth header. That is typical when using the User Defined (OAuth) credential type.
Hi,
Thank you very much for the answer.
I have just one more question (not completely unrelated to JWTs).
Is there a feasible way to use one generated (JWT) token as authorization for all data actions performed in IVRs for a time period until it expires, and then get a new one via a refresh token, and then switch all new interactions to use the new token.
The only idea i have is to use data tables, but storing temporary access tokens there could be a security risk, and there may be some failed actions from customers who tried to use an expired token (for example they called just as it was about to expire)
Any ideas? Is this even possible through architect?
At a high level it depends on what it takes to generate the JWT. If you can generate a new token in a custom auth action using the refresh token, then everything will work exactly like you want it to out-of-the-box.
If there are signing / hashing / other requirements that are beyond the capability of a custom auth action then you could do something like this:
Setup the integration as a custom auth type, with the token as the only field. You will need the ID of the credential that you configure for this. The easiest way to get this is to open the developer console in your browser when you create the credential in the UI. Otherwise you could create/update your integration via API.
Then you would then need something that could periodically refresh the token and update the credential via the
PUT /api/v2/integrations/credentials/{credentialId}
route.
That could be anything, a stand alone service that runs on a timer, or maybe even a Lambda data action to get a fresh token followed by a Genesys Cloud data action to update the credentials (although getting it to run once at the right time seems tricky).
During development you will probably want to do a get on that credential ID to get an idea what it should look like.
