Use cases for Service Accounts in Okta

Okta does not currently support the concept of service principals (feature request! @Okta 😊) Service Principals are a better way to manage application permissions, see examples from Microsoft: https://learn.microsoft.com/en-us/entra/architecture/secure-service-accounts#service-principals.

In Okta service accounts refer to accounts created to perform actions on behalf of an application’s API, a common use case is to create, update and deactivate users in an application external to Okta. Service accounts are created by a human, the credentials must be stored and managed and an Okta license is dedicated to each service account.

This guide aims to provide clarification on use cases for service accounts in Okta and Applications connecting to Okta.

If service accounts are not used, this creates issues and risks within your Okta tenant:

1. [MOST IMPORTANT] Business continuity is at risk if accounts belonging to employees are deactivated. The API integrations within Okta and those linking to external applications will break, this is a massive headache to fix. 🙁
2. The Okta System Logs will create system logs with the account who has authorized the connection as the Actor.

If API connections are broken in SCIM, a reconciliation exercise must be done between Okta and target apps when the connection is re-authorized, Okta performs Create/Update/Deactivate actions based on event triggers (e.g. user leaves organization) and will not retrospectively update users in the target app. This means a user can be DEACTIVATED in Okta, but their account is ACTIVE in the target app.

1. Creating API Tokens in Okta

• Use a service account with the appropriate level of admin privilege required.
• Log into Okta with the service account and create the API Token- the user who creates the token is the owner of the token.
• If the token owner is deactivated, the API token will be deactivated
• This includes creating an API token for Org2Org integrations

2. Integrating Active Directory to Okta

• After running the AD Agent installer, you will be asked to authenticate to Okta- this should be done with a service account with admin privileges in Okta, the authorization action creates an API token in Okta

3. Authorizing Okta Workflow Connectors

• Note- authorization is a different action to creating the Workflow Connector
• Okta Workflow Connector- use an Okta service account
• External Workflow Connectors – use a service account in the external application

4. Authorizing Application Integrations for SCIM

• Use a service account in the External application to authorize the connection or create an API token.

About The Author
Lynsey Dunn is an IAM Consultant and Certified Okta Consultant at Distology Studios, bringing extensive Risk Analyst experience from previous positions at Deutsche Bank and Morgan Stanley.