I am using Connect to build an app for Jira and I want to authenticate users on our side and store an apiKey (expires) as user property in Jira Cloud.
My question is am I allowed to send the clientKey and the accountId (base64encoded) at least to my app to identify a user and to be able to use the already stored data for the clientKey to generate a valid JWT token in order to set my apiKey as a user property?
- Store tenant related data on /install using clientKey as primary key
- User clicks connect to our app button inside an issue glance on Jira
- A new window will appear where I send clientKey and accountId (sub) as get parameters (base64encoded)
- The user logs into our app with his credentials successfully
- I generate a JWT token based on the clientKey related data from DB and the accountId I just received
- I send a request with the newly created JWT token to my app and store the api key to the specified accountId
If the above actions are not allowed, are there any alternatives to achieving what I proposed above?
Any info related to this would be appreciated.
There is nothing wrong with sending the clientKey and the accountId. In fact, they are already available to you via the JWT generated by Atlassian, which can be retrieved client-side by calling
AP.context.getToken(). The JWT is signed with the
sharedSecret you received in the install event, so you can confirm the authenticity of the request.
Hence, I would suggest to replace step 3 with
A new window will appear where I send the JWT generated by AP.context.getToken() as get parameter
Thank you for your answer, but from my understanding the context tied JWT is available only between the Jira Cloud app and Jira (please correct me if I am wrong), and from what I saw (the token content) I cannot really use it to send requests back from a third party app back to my Cloud app.
Indeed, you cannot use the context JWT to make requests to the Jira Cloud API. However, that was not what I inferred from step 2-3. You were talking about transferring the required user data to your system in order to identify the user / instance which you will need for step 5-6.
To that avail, my proposal was to use the context JWT instead of sending only clientKey and user accountId in the get parameters. This is because the JWT can be verified on your end using the sharedSecret. This would add an extra level of security.
I understand now what you suggested, I will try to follow the path you suggested first.
Thank you for your answer!