Okta API calls are often executed using administrator-created SSWS API Tokens, which allow an API Client to operate as if it were that admin. Through OAuth for Okta, it is possible to issue Bearer Tokens using Admin Sign-Ons or through an API client that uses OAuth Bearer Tokens to perform the same tasks in a much more secure and flexible manner.

• API Access Management
• Okta APIs
• OAuth for Okta

When using OAuth for API calls within Okta, there are several advantages not afforded by SSWS API calls:

• Okta's API Scopes can limit the access granted by OAuth Bearer Tokens to specific API actions, making them more granular in scope than Custom Admin Roles.
• OAuth Bearer Tokens are ephemeral, lasting only 1 hour, which limits the exposure should any one Token be compromised.
• SSWS Tokens can not be generated using the API, only in the Okta Admin Console.
• SSWS API Tokens are difficult to rotate and are designed to have a rolling 30-day expiration, whereas OAuth Bearer Tokens are generated on demand at the time of the request.
• If the admin account that owns an SSWS Token is compromised or otherwise deactivated, that API Token will break, causing issues with any and all apps using it.
• When tracing logs for OAuth Tokens, it is possible to track them by the app and then to the user or service using the application, as well as determine exactly what scopes were granted, allowing for easy auditing of API activity.

Related References

• Implement OAuth for Okta with a service app
• Implement OAuth for Okta
• Why You Should Migrate to OAuth 2.0 From Static API Tokens