Atlassian Identity
Twin of Atlassian Cloud's OAuth 2.0 (3LO) authorization server.
The 3LO authorization server on auth.atlassian.com. It mints the access tokens
the Jira twin verifies.
| Covers | auth.atlassian.com |
| Auth | OAuth client id and secret |
| Issues tokens for | Jira |
| Operations | 2 |
Coverage
Two grants: authorization code and rotating refresh token. Client credentials is
refused the way Atlassian refuses it. The endpoints behind them are authorize
and token, and nothing else: Atlassian publishes no discovery document, no
userinfo and no product resources on this host, so a client library that
bootstraps itself from /.well-known/openid-configuration finds none here
either. Jira’s own API traffic goes to the Jira twin.
This twin is added to your environment automatically when you ask for Jira, so you rarely request it directly.
Credentials
Any well-formed client id and secret authenticate by default; a missing one is
always refused. Set auth.mode to enforced to accept only the client the
world lists. See Credentials.
Vendor specific details
- Refresh tokens rotate on use. Presenting a superseded refresh token again
within ten minutes returns the same replacement pair instead of
invalid_grant, so a retried refresh is safe. After that window it is refused. A refresh token’s hard lifetime is 90 days. - The code exchange reads client credentials from the body only. HTTP Basic on that grant is refused, while the refresh grant accepts either placement.
audience=api.atlassian.comis required on authorize. Anything else isinvalid_requestwith “audience is invalid”.- A
GET /authorizewith no query string at all redirects to the Atlassian login page before validating anything, so an empty request looks like it worked.
Its own notes
Once a sandbox is running, this twin serves its own operating notes at
{control_url}/veris/manual: the credentials it accepts, the API versions it
serves, and the fault statuses you can arm against it. They are generated from
the same source as its behaviour, so they cannot drift.