About the format of Atlassian security tokens

Recently, @GuilhermeBueno and I worked a support case about the OAuth 2.0 authorization code exchange. The first step of the flow in OAuth 2.0 (3LO) apps is retrieving the authorization code by directing the user to the authorization URL. The authorization code is returned as a parameter in the URL. The OAuth 2.0 specification does not specify how that authorization code is formatted or what size it should be.

In our case, the reporter noted the authorization code from Atlassian was once returned as an opaque code and is now a JWT token. This change is part of the ongoing changes in implementation announced with the Jira Cloud Platform changelog. Indeed, clients are unaffected by this change and you may follow the same process for retrieving the access tokens for the OAuth 2.0 (3LO) apps, as it’s defined the in documentation page. (In case you do notice any issues, please reach out here in the Developer Community or raise a bug with our Developer Support team.)

As in this case, Atlassian considers the authorization code and all API tokens to be opaque in the sense that clients cannot depend on their size, structure, or format. We may use a particular format, like JWT, for our internal implementation. So, generally, clients should treat all security tokens as indeterminate length string data.