Who this affects
Everything that calls the ACB API with a Refresh Token: CI/CD pipelines, scripts, SOAR playbooks, CMDB integrations, external secrets vaults, and any use of the ACB Console CLI that passes a token. It applies to Application Accounts, Internal users, and Active Directory users with the external-application toggle enabled.The timeline
The transition period runs for three months from the date you update the Application Server, not from the release date. The expiry date set on each Refresh Token is stored in the database and is not displayed in the Management Tool, so calculate your deadline from your own update date.
What happens when the transition ends
- Requests sent with an expired Refresh Token are rejected.
- Every field in the Refresh Token-Based Authentication section is disabled: Refresh Token, Authorization token lifetime (sec), and IP Address restriction.
- The ACB Console CLI accepts only Bearer access tokens. Refresh Token authentication is no longer supported there.
Clean installations
If you install 7.28 or later on a server that never ran an earlier version, there is no transition period. Refresh Token authentication is unavailable from the start: the fields are disabled and not editable, Refresh Tokens can’t be generated, regenerated, or modified, and API requests using them are rejected.Warnings you will see
The Transaction Log on the System Health dashboards records the migration for you.
Because the Refresh Token expiry date isn’t shown in the Management Tool, the 30-day warning is your first in-product signal. Don’t wait for it: if you updated the server, you already know the deadline.
Migrate an integration
Work through this once per integration. During the transition both methods work, so you can migrate them one at a time and roll back if something breaks.1
List what uses the Refresh Token
Check the Transaction Log for deprecated endpoint records. Each one names the account making the call, which tells you what still needs migrating.
2
Create a Client Secret for the integration
Open the account on the Users page, go to the User Details tab, and add a Client Secret in the Client ID / Client Secret authentication section. Name it after the integration that will use it. See Set up a user account for the field reference.Give each integration its own Client Secret rather than sharing one. Rotating a shared secret breaks everything that holds it.
3
Copy the Client ID and the Client Secret
The Client Secret is displayed once, in the Client Secret Generated window. Copy it into your secrets vault before closing the window.
4
Carry over the IP restriction and token lifetime
If the Refresh Token had an IP Address restriction, set the same restriction on the Client Secret. Set Access Token Lifetime to suit the integration, remembering that it is in minutes here and the legacy field was in seconds.
5
Update the integration
Change the integration to request an access token with its Client ID and Client Secret, then send that token in the Authorization header using the Bearer scheme. For the ACB Console CLI, pass
--token_type Bearer; without it, the CLI falls back to the legacy Refresh Token behaviour.6
Test, then confirm the old path is unused
Run the integration and confirm it works. Then watch the Transaction Log: once no more deprecated endpoint records appear for that account, the migration is done.
Things worth knowing before you plan
Access tokens are invalidated when the ACB service restarts
Access tokens are invalidated when the ACB service restarts
If the service is restarted, every access token issued before the restart becomes invalid, and integrations must request a new one with their Client ID and Client Secret. Build token re-request into your error handling rather than caching a token for its full lifetime and assuming it holds.
Obtaining a new token doesn't invalidate the old one
Obtaining a new token doesn't invalidate the old one
If an account obtains a second access token, or the user signs in to the Management Tool, the first access token stays valid for its configured lifetime. Tokens expire on their own schedule.
Invalid Client Secrets count toward account lockout
Invalid Client Secrets count toward account lockout
Authentication attempts with an invalid Client Secret are treated as failed authentication attempts and count toward the account’s lockout threshold, the same as failed passwords. An integration retrying with a stale secret can lock the account.
Rotation invalidates the old secret immediately
Rotation invalidates the old secret immediately
There is no grace period. The moment a new secret is generated, the previous one stops working. Rotate and deploy in the same window.
Client Secrets expire, and the maximum is 365 days
Client Secrets expire, and the maximum is 365 days
Unlike Refresh Tokens, Client Secrets carry an expiry date, with a maximum validity of 365 days. Migration isn’t a one-off: put secret rotation into your normal operational schedule and use the Transaction Log warnings as the backstop, not the plan.
Troubleshooting
Related
Set up a user account
Create the account and configure Client ID / Client Secret authentication.
System Health dashboards
The Transaction Log, where expiry and deprecation warnings appear.
Audit log
The record of Client Secrets added, edited, rotated, and removed.
ACB CLI
Console commands and the token type parameter.
API reference
Base URL, authentication, status codes.