-
Type:
Suggestion
-
Resolution: Unresolved
-
None
-
Component/s: OAuth 2.0 Client
-
None
The introduction of the Admin API Key system is good as it allows centralised management of API keys by our tenancy admins and movement away from needing over priviliged service accounts, however the 12 month expiry of these tokens introduces risk of outages for business processes that rely on API key access, and operational overhead in doing manual rotations. The guidance specified at https://support.atlassian.com/organization-administration/docs/manage-an-organization-with-the-admin-apis/ indicates that this can only be done via the dashboard via provisioning of a new key. This mechanism is also at risk of expiries being set incorrectly or granular permission scopes being incorrectly configured, and I expect customers needing this functionality will instead be inclined to use less secure Robotics Process Automation to provision these keys in an automated fashion.
It would be ideal if we instead had a mechanism to rotate API keys that maintain their scoped granular permissions, reset the expiry date to a new future date, and return a secret, so that the key can be enrolled into a KeyVault. I understand the ability to generate new keys and scopes via APIs introduces additional security issues, so I think a dedicated key rotation mechanism would make the most sense.
For example (based on https://developer.atlassian.com/cloud/admin/api-access/rest/intro/#about)
PATCH /orgs/{orgId}/api-keys/rotate/{apiKeyId}
{
"newKeyExpiresAt": "2025-12-31T23:59:59Z",
"oldKeyExpiresAt": "2025-08-31T00:00:00Z",
"rotateReason": "Scheduled key rotation as part of security best practices",
"notifyContacts": true,
"metadata": {
"rotatedBy": "user@email.com",
"initiatedFrom": "CI/CD Automation",
"rotationPolicyId": "rot-policy-companyID-standard"
}
}
| Field | Type | Description |
|---|---|---|
| rotateReason | string | Optional. Human-readable reason for audit logging. |
| notifyContacts | boolean | Optional. If true, notifies security contacts or owners. |
| metadata | object | Optional. Contains additional context such as initiator identity, automation source, or policy mapping. |
| rotationPolicyId | string | Optional. Links to a pre-defined org-specific key rotation policy. |
| rotatedBy | string | Optional (within metadata). Identity of the user or service that triggered the rotation. |
| initiatedFrom | string | Optional (within metadata). Could indicate manual, UI, API, Terraform, etc. |
Response
{
"data": {
"id": "new-api-key-789",
"encryptedSecret": "kO3H1zBNpEuXGFnxT0IYzQaZQ1lOj0ZkpDs6dE1p4B8=",
"encryption": {
"algorithm": "AES-256-GCM",
"pskId": "azupay-kms-default",
"keyWrap": false
},
"keyExpiresAt": "2025-12-31T23:59:59Z"
}
}
To enhance security the rotation could also be secured via a preshared key for the returned encryption key managed via the UI sucha s a 256 key set for Key rotations.
I appreciate this may be under the wrong product/component. I was unable to identify where to raise it and the Atlassian Ecosystem suggestions requires a component but the project has none to set.