Identity · Identity + SCIM

Use Okta for staff access and provisioning.

Use Okta for staff sign-in, exact group-to-role rules, and SCIM user and group provisioning.

Create a free workspace Read current API behavior

How the connection works

How Okta works with the gateway

Keep sign-in and SCIM explicit

OIDC or SAML handles sign-in. SCIM handles user and group changes. Enabling one does not silently enable the other.

Map exact groups to fixed roles

An owner chooses the Okta groups that map to built-in gateway roles. Partial group names and email matches do not grant access.

Know what remains

The private integration path exists. Live Okta conformance and an Okta Integration Network listing are not complete.

Current shared controls

What every supported connection includes

Encrypted BYOK credentials that remain hidden after setup Stable model aliases and compatible route targets Organization and key budgets, rate limits, and concurrency limits Observe, Shadow, and Enforce modes with metadata-only evidence

Test sign-in, group changes, deprovisioning, and tenant isolation with the customer's Okta configuration before production use.

Client boundary

AIGHQ_BASE_URL=https://api.aigatewayhq.com/v1
AIGHQ_API_KEY=from-your-workspace
AIGHQ_MODEL=company-approved-fast

Okta manages staff identity and lifecycle. It does not store provider keys, route model requests, or grant access from an email-domain match.

Implemented boundary

Supported protocols

An owner adds a private Okta application, validates its OIDC issuer or signed SAML metadata, maps exact groups to built-in roles, and enables SCIM separately. Live Okta conformance remains a planned check.

OIDC or SAML 2.0 sign-in SCIM 2.0 Users and Groups Exact group-to-built-in-role rules

Compatibility follows the provider's current published interface. Review the provider documentation before approving Okta for production.