Audit Okta API Tokens and Service Apps Step by Step

Okta API tokens and OAuth service apps are the machine credentials that can change your identity provider itself, and most tenants have never inventoried them. An SSWS API token carries the full admin privileges of the person who created it, and a service app with the wrong role or scope grant can create users, reset factors or rewrite policies. This guide is a repeatable audit: list every API token and service app, score each one against a short set of risk tests, and reduce or remove what fails, with the Okta Admin Console paths and Management API calls for each step. It is for Okta administrators and identity security teams. Tenant-wide hardening is covered in the Okta Security Hardening Guide.

Key takeaways

API tokens are as powerful as their creator. Okta documents that an API token inherits the privilege level of the admin who created it and is not scoped any further, so a token made by a super admin is a super admin.
Tokens die with their creator. Tokens are valid only while the creating user is active, and expire after 30 days without use; both facts tell you which tokens are dormant and which will break on offboarding.
Service apps are the better pattern, but audit them too. An API Services app gets one-hour access tokens limited to granted Okta scopes, but its admin role assignment and scope grants can still add up to super admin.
Watch the automatic super admin setting. Okta's Public client app admins setting can auto-assign the super admin role to service apps after scopes are granted; Okta itself recommends turning it off once roles are assigned deliberately.
Prove "unused" with data. Cloudflare was breached through credentials it believed were unused; last-used dates and System Log events are the evidence.

When you need this

Periodic access review: quarterly, as part of privileged access certification.
After an Okta-related incident at your organisation or a supplier. In the Cloudflare Thanksgiving breach, four credentials stolen in the Okta support system incident, including integration service accounts, were left unrotated because they were thought to be unused.
Admin offboarding: before deactivating an admin, find the tokens they created, because those tokens stop working the moment the account is deactivated.
Migration away from SSWS tokens to OAuth 2.0, which Okta strongly recommends.

Before you start

Use a read-only path for discovery. Run the inventory with a dedicated service app granted only okta.apiTokens.read, okta.apps.read and okta.logs.read, or as an admin in the Admin Console. Do not mint a new super admin API token for the audit.
Confirm who can change things. Only the Super Admin role can grant Okta API scopes to an app; plan approvals accordingly.
Agree the risk tests below with the owners of integrations, and set a change window for anything you will revoke.
Export a baseline of the token list and app list before you change anything.

Credential	How it authenticates	Privilege comes from	Lifetime
API token (SSWS)	`Authorization: SSWS <token>`	The creating admin's roles, at all times	30 days from creation or last use; revoked if the creator is deactivated
API Services (service) app	Client credentials grant, `private_key_jwt` for Okta scopes	Granted Okta API scopes plus admin roles assigned to the app	Access token fixed at one hour; the key or secret lasts until rotated
Agent token	Used by Okta agents (for example AD agents)	The agent's function	Revocable only when the agent is not active

Step-by-step

Steps 1 to 5 are read-only. Step 6 changes access and is destructive for the integrations involved.

List API tokens. In the Admin Console go to Security, API, Tokens. The list shows token name, ID, role, status, type and last used; the creator appears under Role, and a token's History section shows creation, last-used and expiry dates. A yellow status marks a suspicious token tied to an agent not registered in Okta. Through the API, GET /api/v1/api-tokens returns metadata for active tokens, including name, userId (the creator), clientName, created, lastUpdated, expiresAt, tokenWindow and network.
Resolve each creator's privileges. For each userId, record the user's admin roles. That is the token's real privilege. Flag tokens created by personal admin accounts, by super admins, and by users about to leave.
List service apps. Under Applications, filter to API Services apps, or call GET /api/v1/apps?filter=status eq "ACTIVE" with paging (limit, after) and keep apps whose settings.oauthClient.application_type is service. For each app record:
- Scope grants: the Okta API Scopes tab, or GET /api/v1/apps/{appId}/grants.
- Admin roles: the Admin Roles tab, or GET /oauth2/v1/clients/{clientId}/roles, plus any group or app targets on those roles.
- Credentials: client authentication method (credentials.oauthClient.token_endpoint_auth_method), GET /api/v1/apps/{appId}/credentials/secrets and GET /api/v1/apps/{appId}/credentials/jwks.
Pull usage from the System Log. Query GET /api/v1/logs with since and until for the review period. Okta documents that the event transaction object carries the API token ID, so you can tie API activity to a specific token. For service apps, look for app.oauth2.as.token.grant.access_token events for the client. Also pull changes: app.oauth2.admin.consent.grant, app.oauth2.client.privilege.grant, app.oauth2.credentials.lifecycle.create and app.oauth2.client.read_client_secret. Detection rules are in the Okta System Log Detection Guide.
Score each credential against the tests in the table below and assign an owner and a decision: keep, reduce, migrate or remove.
Remediate (destructive).
- Revoke a token: the trash icon (Revoke token) in the token list, or Revoke token on its page, or DELETE /api/v1/api-tokens/{apiTokenId}. There is no undo; the integration needs a new credential.
- Restrict a token you must keep: add a network condition in the token's Security section, or PUT /api/v1/api-tokens/{apiTokenId}, so it works only from named zones.
- Reduce a service app: revoke unneeded scopes with DELETE /api/v1/apps/{appId}/grants/{grantId}, and unassign broad roles with DELETE /oauth2/v1/clients/{clientId}/roles/{roleAssignmentId}, replacing them with a targeted or custom role.
- Retire a service app: POST /api/v1/apps/{appId}/lifecycle/deactivate first; delete only after a quiet period.
- Move off client secrets: switch the app to Public key/Private key client authentication. Okta warns this deletes existing client secrets, so deploy the new key to the integration first.

Risk test	Fails when	Remediation
Creator privilege	API token created by a super admin or org admin	Migrate to a service app with named scopes and a narrow role
Creator identity	Creator is a named person rather than a dedicated service account	Recreate under a controlled service account or migrate; tokens break when the person leaves
Usage	No use in 30 days (token) or no token grants in the review period (app)	Revoke or deactivate after owner confirmation
Network	No network condition on an API token used from fixed hosts	Add a zone restriction
Role breadth	Service app holds super admin or an untargeted admin role	Replace with a targeted standard role or custom role
Scope breadth	`.manage` scopes granted where `.read` would do	Revoke the grant, re-grant the read scope
Credential type	Client secret instead of a key pair	Move to `private_key_jwt`
Ownership	No named owner or no documented purpose	Treat as orphaned: deactivate after notice

Verify it worked

Re-run the inventory: the revoked token IDs no longer appear in GET /api/v1/api-tokens, and reduced apps show only the intended grants and roles.
Check the System Log for the change events (app.oauth2.admin.consent.revoke, app.oauth2.client.privilege.revoke, app.oauth2.credentials.lifecycle.deactivate) and for failed calls from integrations you changed.
Confirm each kept integration works with its owner, using its new or reduced credential.

Rollback and common errors

Revoked token cannot be restored. Rollback means issuing a replacement, ideally as a service app, not a new SSWS token. Keep the integration owner on hand during the change window.
Deactivated app: a deactivated service app can be reactivated if an integration breaks unexpectedly, which is why you deactivate before deleting.
Secret rotation order: Okta allows up to two client secrets; create the new one, deploy it, then deactivate the old one. You cannot deactivate the only secret, and only an inactive secret or key can be deleted.
Offboarding breakage: deactivating an admin silently invalidates their tokens. Run step 1 filtered by that userId before any admin is deactivated.
"Stable super admin" advice: Okta's help page suggests a stable super admin service account to avoid token interruptions. That avoids outages but maximises blast radius; prefer service apps with least-privilege roles, and if a token must remain, give its service account the narrowest role that works.

Hardening afterwards

Default to service apps with private_key_jwt, targeted roles and read scopes; allow new SSWS tokens only by exception.
Turn off Public client app admins once roles are assigned deliberately, so new service apps do not become super admins by default.
Protect the credential store: the Okta support system breach began with a service account password saved in a personal browser profile. Keep private keys and any remaining tokens in a secrets manager with an owner.
Alert on change events: new scope grants, new role assignments to clients, new credentials and client secret reads.
Review quarterly with this procedure and record decisions as evidence.

Where identity fits: treat every token and service app as a non-human identity in your inventory, with the same fields you hold for a human admin: a named owner, a business purpose, the system that consumes it, its effective privilege and its last review date. The Okta tenant is often the root of trust for everything else, so an over-privileged Okta machine credential is effectively a credential for every application federated to it. Integrations such as ITSM connectors, HR provisioning tools and, increasingly, AI agents that create or update users are the usual consumers. When an integration is retired in another team's system, nobody tells the Okta administrators; the 30-day inactivity expiry on SSWS tokens helps, but that rule is documented for API tokens, not for service app keys and secrets, so the usage evidence from step 4 is what catches them.

Measure it: number of active SSWS tokens (target falling to zero), percentage created by super admins, percentage of service apps using private_key_jwt, service apps holding super admin, credentials with no owner, and days since last review.

Framework	Reference	Relevance
MITRE ATT&CK	T1078.004 Cloud Accounts; T1098 Account Manipulation	Abuse of identity provider credentials; adding roles or grants for persistence
NIST SP 800-53 Rev 5	AC-2; AC-6; IA-5; AU-6	Account review, least privilege, authenticator management, log review
NIST CSF 2.0	PR.AA-01; PR.AA-05	Managed credentials; reviewed permissions

Practitioner checklist

Export the API token list from Security, API, Tokens and record each creator's admin roles
List API Services apps with their scope grants, admin roles and client authentication method
Pull System Log usage for each token and service app across the review period
Score each credential against the risk tests and assign an owner and decision
Revoke unused tokens and migrate super admin tokens to service apps with narrow roles
Move service apps from client secrets to private_key_jwt
Turn off Public client app admins once roles are assigned deliberately
Check tokens created by any admin before that admin is deactivated

How to audit Okta API tokens and service apps: Inventory, score and cut every Okta machine credential