Authentication & IAM Spec (v0)¶
Date: 2026-02-07
Summary¶
Introduce a unified IAM service that provides authentication for human principals, tenant-scoped SSO, local users, API tokens, and MFA. IAM owns permissions and scopes as the single source of truth.
Goals¶
- API-first authentication for human users.
- Support local users and tenant-scoped SSO (OIDC + SAML).
- Provide user-created API tokens with scoped permissions.
- Require MFA for sensitive actions based on tenant policy.
- Record MFA signals from IdP assertions for auditability.
Non-Goals (v0)¶
- Service accounts or machine identities (M2M).
- Full SCIM provisioning (future).
- Passwordless login (future).
- Multi-IdP per tenant (future).
Architectural Recommendation¶
IAM Service (Authn + Authz integration)¶
Start with a unified IAM service for velocity and fewer dependencies. Internally separate authn and authz modules to allow a future split only if required.
Future Split (Optional)¶
If scale or org structure demands it later, consider a split. Ensure token formats and contracts remain stable to avoid breaking changes.
Tenancy & IdP Model¶
- One IdP configuration per tenant (v0).
- Each tenant can be configured for either OIDC or SAML (or both, but one active at a time).
- Login discovery via explicit tenant slug or email domain routing.
Tenancy & Isolation Requirements¶
- All IAM data is tenant-scoped; user actions are additionally workspace-scoped where applicable.
- Tokens must include
tenant_idand activeworkspace_idcontext for downstream authorization. - API handlers must reject tenant/workspace mismatch between token context and requested target objects.
- Cross-tenant user, token, role, and policy access is out of scope for v0 product flows.
- Tenant Admin operations that span workspaces must be explicit and auditable (for example, workspace owner transfer).
Identity Model¶
- User: human principal.
- ExternalIdentity: IdP subject linkage.
- APIToken: user-created token with scopes.
- MFACredential: TOTP (v0), WebAuthn (v1).
Authentication Methods¶
Local Auth¶
- Email/username + password.
- Password reset (email + token).
- MFA policy enforced per tenant.
SSO¶
- OIDC Authorization Code + PKCE.
- SAML 2.0 SP-initiated.
- IdP is responsible for MFA policy. IAM records MFA assertion details when provided.
MFA (Local)¶
Phase 1 (v0): TOTP + Backup Codes¶
- TOTP enrollment with QR code.
- Backup codes generated and stored hashed.
- MFA required for sensitive actions per tenant policy.
Phase 2 (v1): WebAuthn/Passkeys¶
- Add support for passkeys and security keys.
- Used as alternative or additional factor.
MFA Policy (Tenant-Level)¶
mfa_mode: OFF | OPTIONAL | REQUIREDmfa_required_actions: list of actions requiring MFA for local users.
Recommended defaults:
- mfa_mode = REQUIRED
- mfa_required_actions = [LOGIN, CREATE_PAT, ROTATE_PAT, REVOKE_PAT, CHANGE_PASSWORD, MANAGE_USERS, UPDATE_IDP_CONFIG]
API Tokens (PATs)¶
Format¶
- Opaque, random token. Stored hashed.
- Returned once at creation.
- Default expiration: 90 days.
- Rotatable and revocable.
Scope Model¶
- Token scopes map to registered permissions from IAM.
- Effective permissions:
user_permissions ∩ token_scopes
Validation Rules¶
- Token hash match.
- Not revoked.
- Not expired.
JWTs¶
- JWTs used only for short-lived access tokens (15-60 minutes).
- PATs are not JWTs.
Authz Integration¶
- IAM resolves authenticated user and token scopes.
- Authz evaluates permissions using existing registry.
- Services enforce locally using middleware with consistent permission names.
Data Model (Conceptual)¶
User¶
idtenant_idemailstatus(active/disabled)password_hash(local only)created_at,updated_at
ExternalIdentity¶
iduser_idprovider_type(oidc|saml)issuersubjectcreated_at
APIToken¶
iduser_idnametoken_hashscopes(list)expires_atcreated_at,last_used_atrevoked_at
MFACredential (TOTP)¶
iduser_idtype(totp)secret_encryptedenabled_atlast_used_at
MFABackupCode¶
iduser_idcode_hashused_at
TenantIdPConfig¶
tenant_idprovider_type(oidc|saml)issuer(oidc)client_idclient_secret_encryptedsaml_metadatacreated_at,updated_at
TenantMfaPolicy¶
tenant_idmfa_moderequired_actions(list)created_at,updated_at
API Surface (v0)¶
Authentication¶
POST /auth/login(local)POST /auth/logoutPOST /auth/password/forgotPOST /auth/password/reset
SSO¶
GET /auth/sso/:tenant/start(OIDC or SAML)POST /auth/sso/:tenant/callbackGET /auth/sso/:tenant/metadata(SAML)
MFA (Local)¶
POST /mfa/enroll/startPOST /mfa/enroll/confirmPOST /mfa/challengePOST /mfa/backup-codes/regen
Token Management¶
POST /tokensGET /tokensPOST /tokens/:id/rotateDELETE /tokens/:id
Permissions (from IAM)¶
GET /permissions
User & Tenant Admin¶
GET /meGET /users/:idPOST /usersPATCH /users/:idPOST /users/:id/disablePOST /workspaces/:id/owner-transferGET /tenants/:id/idpPOST /tenants/:id/idpPATCH /tenants/:id/idpDELETE /tenants/:id/idpGET /tenants/:id/mfa-policyPATCH /tenants/:id/mfa-policy
Flows¶
Local Login (with MFA)¶
1) User submits credentials. 2) IAM validates password. 3) If tenant policy requires MFA for LOGIN, issue MFA challenge. 4) On success, issue short-lived JWT + refresh token or session.
PAT Creation (MFA Required)¶
1) User requests new PAT with scopes. 2) If MFA required for CREATE_PAT, challenge. 3) IAM creates token, returns full token once.
SSO Login¶
1) Redirect to IdP (OIDC/SAML). 2) IAM validates assertion and extracts subject, email, and MFA details. 3) JIT provision or link user. 4) Issue short-lived JWT/refresh token.
MFA Assertion Logging (SSO)¶
- Capture MFA data from OIDC claims (
acr,amr) or SAML context. - Store on login event for auditing and support diagnostics.
Auditing & Observability¶
- Log: login success/failure, MFA events, token create/rotate/revoke, IdP config updates, workspace owner transfer.
- Metrics: login failure rate, MFA failure rate, token usage rate.
Security Requirements¶
- Password hashing: Argon2 or bcrypt.
- Rate limiting on auth endpoints.
- Token hashing and secure storage for secrets.
- Enforce token expiration (90 days default).
- Encrypt IdP client secrets and MFA secrets at rest.
Open Questions¶
- Do we require step-up MFA for SSO sessions on sensitive actions?
- Should refresh tokens be rotated on every use?
- Default session model for UI vs API-only clients?
Next Steps¶
- Confirm MFA step-up policy for SSO.
- Define exact permission registry schema for token scopes.
- Decide on refresh token design (rotating vs fixed).