REST API errors when JWT in Header, but as a URL param it's fine

Jira Development Jira Cloud
,
1

When using the JIRA Cloud REST API (creating issues, getting projects, etc) from our Connect App, we originally used a JWT in a “Authorization” header. i.e. Authorization: Bearer <JWT>

I believe we must have changed something (app scope?) and started receiving error responses. We added the JWT as a URL Param and it succeeded, i.e. POST /rest/api/2/issue?jwt=<JWT> returns a 200 and a created issue.

The error we get when using the JWT in a header when attempting to create an issue is:

HTTP/2.0 400 Bad Request
{"errorMessages":[],"errors":{"summary":"Field 'summary' cannot be set. It is not on the appropriate screen, or unknown.", "description": "Field 'description' cannot be set..."}}

Which leads me to believe we’re not providing the correct context in the JWT. However, I don’t understand why using the same JWT (aside from timestamps) works as a URL param for the same endpoint.

I’ve verified the payload in the JWTs used in both cases are the same, i.e.

{
  "exp": 1528178462,
  "iat": 1528176662,
  "iss": "<app-key>",
  "qsh": "<qsh>"
}

Any idea what we’re doing wrong when using the JWT in an Authorization header?

2

Sometimes I question my own sanity. :wink: Blame kiddos…

I believe we should be using Authorization: JWT <jwt> and not the cough cough standard of Authorization: Bearer <token>.

If there is any background on why it’s JWT and not Bearer would be interested to read about it. Not a big deal tho.

1 Like
3

@andy.ennamorato, so you are saying that when using Authorization: Bearer you get the 400 error for the summary field? That sounds very odd.

As to the choice of HTTP authentication scheme name, I’m not familiar with the history behind that. But I don’t think the JWT tokens used by apps to authenticate with Atlassian product APIs really meet the definition of Bearer tokens:

  • They are issued by clients, not by Atlassian.
  • They do require possession of cryptographic key material.

Additionally, although not strictly violating the definition of Bearer tokens, these tokens are transparent and typically meant to be single-use.

Still, “JWT” is not a standard HTTP authentication scheme. I’m not really sure where that came from, but we’re not the only ones using it.

If it helps at all, per the roadmaps for our Developer Platform and for the Jira Cloud Platform API, we are finally introducing support for standard OAuth 2.0 flows which aims to replace many current usages of JWT authentication.

1 Like
4

Correct, when using Authorization: Bearer we always get errors. FWIW, this is with JIRA Cloud…

Auth0 and other JWT-centric api’s use Authorization: Bearer..., but clearly I just misread the docs.

thanks for the links to the roadmaps, I’ll keep an eye on them.

5

As far as my understanding goes we use Authorization: JWT ... unless we’re impersonating an end-user in which case we make a request to https://auth.atlassian.io/oauth2/token first and use part of the response as Authorization: Bearer ... when speaking to Atlassian.

[Edit]: see User impersonation for Connect apps for the ‘Authorization: Bearer’ stuff and Security for Jira Cloud apps for the ‘Authorization: JWT’ stuff