You’re adding sign-in for individual people — not companies. Each user is their own account: they register, pick how they authenticate (password, passkey, a social provider, a one-time code), stay signed in across their devices, and manage their own security. There’s no organization boundary to model. This page is the whole path — from the user model, to choosing an integration, to a working login flow, to going live.

If your product is instead sold to companies — where users belong to tenant organizations and admins invite teammates — start with the B2B SaaS pillar. For non-human callers, see Agents & services.

The path

1. Understand the user, session, and token model → concepts
2. Choose your integration shape → decision
3. Build a working sign-in flow → quickstart & guides
4. Harden for production → go-live checklist
5. Look up exact request/response behavior → API reference

---

1. Understand the model

Two concept pages carry a consumer login integration — fifteen minutes total:

• Users — the person who signs in: identity (email, phone, or a chosen username), profile, and the authentication methods they can hold at once (password, passkeys/WebAuthn, social/OAuth providers, email & SMS OTP, TOTP, and backup codes). The same page covers verification, account lockout, and the sessions and tokens (ID, access, refresh) that track a signed-in user across devices. This is the core page — don’t skip it.
• Clients — the application users sign in through, and the flow it uses (Authorization Code + PKCE).

New to the platform entirely? Start with the five-minute overview.

2. Choose your integration

Three decisions determine your integration shape:

Decision	For consumer login, usually…	Details
Which API?	The IdP API for the sign-in runtime (OAuth 2.0 / OIDC). Reach for the Core API only to read or manage user records from your backend.	The two APIs
SDK or raw OIDC?	The AuthPI SDK (@authpi/idp) — it handles PKCE, token exchange, and refresh. Drop to a raw OIDC library only if you already have one.	SDKs
What client type?	A Web client for a server-rendered or backend-for-frontend app; a SPA (public) client for a browser-only app — both use Authorization Code + PKCE.	Clients

Which authentication methods to offer is a product decision, not an integration one — you configure them on the issuer and they all surface in the same hosted flow, so nothing in your code changes.

3. Build it

Pick your framework and wire the OIDC flow — login route, callback, protected pages, logout:

• Next.js — App Router, Authorization Code + PKCE, with the SDK or any OIDC client
• Hono — login, callback, protected route, and logout end to end
• Cloudflare Workers — verify access tokens in a Workers API
• All quickstarts

Then layer in the flows a consumer app needs:

• Manage and revoke sessions — let users see their devices and log out individually or everywhere
• Validate tokens in your API — verify the access token on every request
• Custom metadata — attach your own fields to a user record
• IdP SDK — TypeScript — the login flow, session refresh, and revocation in one place

4. Go to production

Don’t ship until you’ve worked through these:

• Verify tokens correctly — signature, iss, aud, typ, and expiry, on every request
• JWKS & key rotation — cache keys, handle an unknown kid on rotation
• Session revocation & the kill-switch — what revocation does to outstanding tokens, and how to cut off a compromised account completely
• Webhooks — react to user.created, user.verification.succeeded, session.compromised, and password-reset events instead of polling
• Rate limits — what applies to your backend’s Core API calls
• Token claims — know which claims your app reads; user tokens carry dat.type: "identity", so agent or key tokens can never be mistaken for a signed-in person

5. API reference

When you need exact parameters and response shapes:

• IdP API reference — the OIDC/OAuth runtime endpoints (authorize, token, userinfo, logout)
• Users — Core API — read and manage user records from your backend
• Sessions — Core API — list and revoke sessions
• Token claims — every claim in a user token
• OIDC compliance — discovery, supported flows, and standards conformance