We have Connect app APIs, which frontend code calls. The API calls are authenticated with a Context JWT (window.AP.context.getToken()
).
We are using the context claim provided in the JWT to ensure the user is logged in when calling the API and that the context is what we expect (for example, checking that there is a project and issue ID).
The problem is that the Context JWT payload for a request made from the issue view and the JSM request portal view look identical (see the example below). This means that just by looking at the context, the app cannot conclude where the request came from or where the Context JWT has been generated.
Context JWT payload example
{
"sub": "547058:2b662b62-7159-81f8-885a-87f02b2d947f",
"qsh": "context-qsh",
"iss": "f92554b7-54e4-2def-bf4d-c86623e5e75a",
"context": {
"url": {
"displayUrl": "https://example.atlassian.net",
"displayUrlServicedeskHelpCenter": "https://example.atlassian.net"
},
"jira": {
"issue": {
"issuetype": {
"id": "10001"
},
"key": "ENG-2",
"id": "10016"
},
"project": {
"key": "ENG",
"id": "10002"
}
}
},
"exp": 1723173744,
"iat": 1723172844
}
The only way I found to fix this is to call GET /rest/api/3/user
with the JWT sub
claim on each API request to verify that the accountType
is not customer
.
Is there any better way to verify these API calls and to distinguish where a call came from?
@atlassian Could the context claim be extended with the Jira module that generated the JWT, similar to the context that we get in Forge?