What Identity owns
Taifa Identity has four service boundaries. The Go authentication service issues OIDC tokens and checks credentials. Its separate Svelte authentication UI owns the central sign-in journey. The Python management service reviews people, Institutions, projects, and product eligibility. The Svelte portal owns account and management workflows plus its own product session. Each integrated product still owns its accounts, roles, tenant filtering, and protected resources.
Choose the right boundary
| Work | Owner |
|---|---|
| Password, TOTP, passkey challenge, authorization code, ID and access token | Authentication issuer |
| Staff sponsorship, project approval, account-link review, lifecycle events | Management service |
| Central sign-in forms, browser binding, CSRF and central session handoff | Authentication UI and its backend |
| Portal login transaction, callback, product session and account screens | Portal backend and UI |
| Local account, product roles, records, sessions, and access checks | Your application |
An OIDC sign-in proves the user’s identity. It does not create a product role or make an Institution membership effective. A product checks its local authorization and current lifecycle state before granting access.
How shared sign-in works
- A registered application creates its own login transaction, state, nonce and PKCE verifier, then redirects the browser to the configured Taifa issuer.
- The issuer and central authentication UI check the current session and the application’s required authentication strength. A usable central session can avoid another password or passkey prompt; fresh or stronger authentication may still be required.
- The issuer returns a one-use authorization code to that application’s exact registered callback. The application redeems it using the original verifier and validates the signed response.
- The application resolves the exact
(issuer, subject)account link, checks current project and Institution access, and creates its own local session. - A second registered application repeats this flow using its own client and callback. It can reuse the central sign-in session, while keeping its own cookies, tokens and authorization checks.
This is the intended integration contract. Mounted development acceptance covers two synthetic clients. Real project registration, person assignment, product integration and complete logout acceptance remain required before rollout. Products do not share a session cookie or copy another project’s access token.
Current integration path
The Go issuer remains restricted to isolated development with AUTH_DEV_INSECURE_LOOPBACK=1 and a disposable loopback database. The portal uses its own confidential client, taifa-identity-portal; a separate mounted HTTPS acceptance exercises two synthetic clients, token audience isolation and central browser SSO. Reviewed installation of real project clients, person assignments, complete product logout and production acceptance remain gates. Use the quick start for the local portal exercise and platform status for the broader integration boundary.
Management exposes a versioned API and reviewed workflows. Its current client delivery adapters and some portal paths still reflect the previous provider, so a reviewed management client record is not yet a Go issuer registration. The client registration guide explains what a future application must provide.
Taifa Identity is intended to be the central OIDC issuer. OIDC_ISSUER is the exact authority URL trusted by a consuming application; it can point to our own service. It does not require an external authentication provider. See the OIDC reference for the issuer settings and token validation rules.
Identity rule
Persist (issuer, subject) as the central identity key. Keep the product’s own account ID. Map central Institution IDs to local tenant IDs explicitly. Email is a delivery and profile attribute; an email match never links accounts or restores access. Read the identity mapping and lifecycle guides before protecting a route.