Hello @alvina_hr , @Florian Bonniec is right on the mechanics: OAuth 2.0 client credentials do not carry an expiry, and API tokens are the credential type built for one. Let me add the governance layer, because your 90-day mandate is achievable and, on service accounts specifically, better than you might expect.
Service-account API tokens: expiry per token, and centrally visible. When you create credentials for a service account in Atlassian Administration (Directory, then Service accounts, then Create credentials, then API token), you set an expiration between 1 and 365 days at creation, so a 90-day token is a direct choice, and you also scope the token to specific products and access levels (read-only where read-only is enough). And the audit answer your security team will like: from that same page, View API tokens shows every token's creation date, expiry, and last use in one place, no hunting through user profiles.
Policy level, if you also govern human users' tokens: with Atlassian Guard, an authentication policy can set API token expiration between 1 and 365 days for its members, so the 90-day rule can be enforced rather than requested. Worth knowing even though service-account tokens are managed per token as above.
The compensating pattern for OAuth, if an integration must use it: treat rotation as a scheduled runbook (rotate the secret on the same 90-day calendar, revoke the old one), keep the service account's scopes minimal, and monitor the org audit log for the account. Most security teams accept "no native expiry, but rotated on schedule with evidence" for OAuth clients when API tokens with real expiry are used everywhere else.
So the practical shape: API tokens with 90-day expiry and scoped access for the service accounts, OAuth only where an integration truly requires it, rotated on the same calendar.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.