Allow API key Management (rotation) via API for Admin API

XMLWordPrintable

    • 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. 

            Assignee:
            Unassigned
            Reporter:
            Adam Parrish
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: