Federated sign-in, and an audit trail that names a person.
Okta connects to NopsAI as a standard OIDC provider. The value is downstream of login: the identity Okta asserts is resolved into an effective subject, and that subject is what authorization, approval eligibility and usage accounting are all evaluated against.
Okta inside a governed run.
How Okta participates once it is connected — and what the platform does with what it returns.
OIDC through your Okta org
Configure the issuer for your authorization server along with the authorization, token, JWKS and userinfo endpoints, the client ID and a credential reference for the secret.
Users created on first sign-in
With auto_create_users enabled, a first successful authentication provisions the NopsAI user, with domain mapping deciding placement.
Restricted to your domains
allowed_email_domains bounds which identities may sign in, and allow_email_linking decides whether an SSO identity may attach to an existing local account.
Subject-aware authorization
Every run resolves an effective subject before dispatch. AAA then answers check, batch-check and filter questions for that subject across the pipeline and the resources it touches.
The controls that make it safe to leave connected.
An integration is easy to add and hard to bound. These are the parts that decide whether it stays reviewable six months later.
Team membership stays in configuration
Okta groups are not synchronized into NopsAI teams — keycloak_team_roles is the only entitlement synchronization mode implemented. Team membership is managed in Git-reviewed configuration, which is auditable but is a manual step when someone changes role.
Secrets never enter the repository
The client secret is stored in the encrypted credential registry and referenced by URI, so the auth configuration can be reviewed by anyone who reviews configuration.
Approvals remain a separate decision
Being authenticated is not being authorized to approve. Approval steps name teams and default to disallowing self-approval, so the person who triggered a run cannot wave it through.
Evidence carries the identity
The subject is recorded on the run and on each AI usage event, so access reviews can be answered from run history rather than from provider logs.
Owned by Git, reviewed like code.
Configuration is a reviewable file rather than a form someone filled in once. Credentials appear as references; the values live in the encrypted registry.
oidc:
enabled: true
auto_create_users: true
default_role: ""
providers:
okta:
type: oidc
display_name: Okta
issuer: https://your-org.okta.com/oauth2/default
client_id: <client-id>
client_credential_ref: credential://system/oidc/okta/client-secret
scopes: ["openid", "email", "profile"]
allowed_email_domains: ["example.com"]Workflows where Okta shows up.
The same integration, seen from the workflow rather than from the connection.
Preparing a release
Scope mismatch, unmerged PRs, failed gates and an outdated runbook can all cause a late surprise.
A security vulnerability scan flags an issue
One vulnerability can span many repos and teams. Manual discovery is slow, incomplete and easy to miss under SLA pressure.
A new employee onboards to a project
Docs go stale, active work is scattered, and every new hire rebuilds the same mental model on their own.
What teams ask about Okta.
Which Okta authorization server should I use?
Either the default server or a custom one — NopsAI needs the issuer plus the standard OIDC endpoints, so whichever server you point at must expose them and include email and profile claims.
Do Okta groups map to approval teams?
No. Group synchronization is implemented for Keycloak realm client roles only. With Okta, membership of the teams named in approval steps is maintained in NopsAI configuration and reviewed in Git.
Can we run Okta alongside local accounts?
Yes. local_enabled keeps password login available, which teams commonly retain as a bounded break-glass path while SSO is the normal route.
Map your Okta workflow end to end.
Bring one real workflow. We will map its trigger, tools, approvals, runtime boundary and evidence requirements with you.