Understand service accounts

How service accounts differ from human user accounts

Service accounts and human user accounts serve different purposes and use different authentication mechanisms. Understanding these differences helps you determine when to use a service account instead of a human user account.

Project scoping

Every service account belongs to a single project. This project scoping provides resource isolation. A service account in one project cannot access resources in another project unless an administrator explicitly grants cross-project access.

When you create a service account, you assign it to a project. The service account operates within the scope of that project by default. To grant a service account access to additional projects, use cross-project delegation.

Use cases

Service accounts are designed for scenarios where external systems need to interact with automation orchestrator without human intervention:

• CI/CD pipelines: Trigger workflow executions as part of a continuous integration or deployment pipeline.
• ITSM platforms: Initiate remediation workflows from IT service management systems when incidents are raised.
• Partner integrations: Exchange data between automation orchestrator and partner or third-party systems.
• Monitoring tools: Call automated response workflows when monitoring alerts are triggered.

Credentials

Service accounts use a separate credential sub-resource for authentication. Each service account can have up to 10 credentials. You create a service account first, and then create one or more credentials for it.

Each credential has a unique client ID with a nx_sa_ prefix, for example nx_sa_7kx9m2p4q1w3n5v8. The prefix identifies service account credentials in logs and support contexts, distinguishing them from other credential types.

Automation orchestrator hashes client secrets with Argon2id, the same algorithm used for human user passwords. This ensures that client secrets stored in the database are protected even if the database is compromised.

When you create a credential or rotate its secret, the plain text client secret is displayed once. It is displayed only in the API response for that operation. You cannot retrieve the client secret afterward. If you lose the client secret, the only recovery option is to rotate to a new secret.

Credential expiration

Credentials can have an expiration date. When you create a credential, automation orchestrator automatically sets the expiration based on the configured maximum credential lifetime. You can also specify a custom expiration, provided it does not exceed the configured limit.

An administrator can configure the maximum credential lifetime. The default maximum lifetime is 180 days. Valid values range from 0 to 730 days, where 0 means the credential never expires. When the maximum lifetime is enforced, credentials that exceed their expiration date are no longer valid for authentication.

When you rotate a credential's secret, automation orchestrator resets the expiration to a new full lifetime from the configured maximum.

Shared JWT infrastructure

Service account tokens use the same JWT signing infrastructure as human user tokens:

• ES256 signing — Service account tokens are signed with the same ES256 key infrastructure used for human user tokens.
• Token validation — The same middleware validates token signatures and checks expiration (exp claim) for both service account and human user tokens.
• Global revocation — The global revocation timestamp applies to service account tokens. If a global revocation event occurs, all tokens issued before the revocation timestamp are rejected. This applies to both human user tokens and service account tokens.

Service account access tokens include a token_type claim set to service_account, which distinguishes them from human user tokens during policy evaluation. The service account API reference includes the full list of JWT claims.

RBAC role assignments

Service accounts receive RBAC role assignments directly. Unlike human users, service accounts cannot be members of groups. This design simplifies the authorization model for machine identities and ensures that each service account's permissions are explicit and auditable.

You can assign both project-scoped roles and global roles to a service account. Project-scoped roles control what the service account can do within a specific project. Global roles grant platform-wide permissions.

Service account resource permissions

Administrators manage service accounts by using the following resource permissions:

Project administrators have implicit management rights over service accounts in their project. No explicit role assignment is required for project administrators to create and manage service accounts.