Your first 24 hours
Create a tenant, register an application, provision the right clients, validate a token, and make the first protected call with tenant context intact.
Register a tenant
Create the identity domain, bootstrap the administrator, choose the plan that matches the evaluation path, and record the returned tenant and organization identifiers.
Create the application
Register the customer application under the organization. Application creation owns the application key, status, external-consumption policy, and plan quota usage.
Provision an InteractiveWeb client
Use Authorization Code with PKCE for user sign-in. Request openid, profile, email, tenant_context, and nexidentity.api.
Provision an Automation client
Use client credentials for the tenant backend or deployment service. Keep the client secret or mTLS material in a secret store and grant only the scopes needed for that workload.
Validate tokens with discovery metadata
Resolve /.well-known/openid-configuration, cache JWKS keys, validate issuer, audience, signature, expiry, and required scopes, then read tenant claims.
Review the audit trail
Use organization audit events and webhook delivery history to confirm sign-in, client, authorization, licensing, and device actions are producing operational evidence.
Provision two clients first
Most tenants need one interactive client for users and one automation client for backend jobs. Manifest publishing has its own current compatibility path.
| Purpose | Flow | Default scopes | Use |
|---|---|---|---|
| InteractiveWeb | Authorization Code + PKCE | openid profile email tenant_context nexidentity.api |
User sign-in for tenant web apps. |
| Automation | Client credentials | Workload-specific machine scopes | Tenant backend service calls and automation. |
| ManifestPublisher | Client credentials, current Basic compatibility path | nexidentity.runtime_manifest_publish |
Publishing application feature manifests. Bearer-token migration is tracked separately. |
Validate before trusting claims
A tenant backend should validate a JWT through the issuer's discovery document and JWKS before using tenant context. Cache signing keys for the configured refresh window and fail closed when signature, issuer, audience, expiry, or scope checks fail.
Tenant context claims
With tenant_context or nexidentity.api, expect user_id, tenant_id, organization_id, membership_id, and perm_ver. Userinfo can also include slug, email, session, name, and preferred username claims.
GET /.well-known/openid-configuration
GET {jwks_uri}
Validate:
- issuer
- audience
- signature
- exp / nbf
- required scope
- tenant_id / organization_id / membership_idContinue from the quickstart
After the first flow works, use the guide and reference routes that match the rollout surface.