> Markdown version of https://authpi.com/docs/use-cases/b2c-login/ — fetch the complete AuthPI docs index at https://authpi.com/llms.txt to discover all available pages.

# Add login for consumer users

The end-to-end path to add sign-in for individual consumers with AuthPI — the user and session model, choosing an integration, wiring the OIDC flow in your framework, and going to production.

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](/docs/use-cases/b2b-saas/). For non-human callers, see [Agents & services](/docs/use-cases/agents-and-services/).

## The path

1. **Understand** the user, session, and token model → [concepts](#1-understand-the-model)
2. **Choose** your integration shape → [decision](#2-choose-your-integration)
3. **Build** a working sign-in flow → [quickstart & guides](#3-build-it)
4. **Harden** for production → [go-live checklist](#4-go-to-production)
5. **Look up** exact request/response behavior → [API reference](#5-api-reference)

---

## 1. Understand the model

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

- [**Users**](/docs/concepts/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**](/docs/concepts/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](/docs/concepts/overview/).

## 2. Choose your integration

Three decisions determine your integration shape:

| Decision | For consumer login, usually… | Details |
|---|---|---|
| **Which API?** | The [IdP API](/docs/reference/idp-api/) for the sign-in runtime (OAuth 2.0 / OIDC). Reach for the [Core API](/docs/reference/core-api/) only to read or manage user records from your backend. | [The two APIs](/docs/concepts/overview/) |
| **SDK or raw OIDC?** | The [AuthPI SDK](/docs/sdks/) (`@authpi/idp`) — it handles PKCE, token exchange, and refresh. Drop to a raw OIDC library only if you already have one. | [SDKs](/docs/sdks/) |
| **What client type?** | A **Web** [client](/docs/concepts/clients/) for a server-rendered or backend-for-frontend app; a **SPA** (public) client for a browser-only app — both use Authorization Code + PKCE. | [Clients](/docs/concepts/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](/docs/quickstarts/nextjs/) — App Router, Authorization Code + PKCE, with the SDK or any OIDC client
- [Hono](/docs/quickstarts/hono/) — login, callback, protected route, and logout end to end
- [Cloudflare Workers](/docs/quickstarts/cloudflare-workers/) — verify access tokens in a Workers API
- [All quickstarts](/docs/quickstarts/)

Then layer in the flows a consumer app needs:

- [Manage and revoke sessions](/docs/guides/session-management/) — let users see their devices and log out individually or everywhere
- [Validate tokens in your API](/docs/guides/validate-tokens/) — verify the access token on every request
- [Custom metadata](/docs/guides/metadata/) — attach your own fields to a user record
- [IdP SDK — TypeScript](/docs/sdks/idp-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**](/docs/guides/validate-tokens/) — signature, `iss`, `aud`, `typ`, and expiry, on every request
- [ ] [**JWKS & key rotation**](/docs/reference/jwks-key-rotation/) — cache keys, handle an unknown `kid` on rotation
- [ ] [**Session revocation & the kill-switch**](/docs/guides/session-management/) — what revocation does to outstanding tokens, and how to cut off a compromised account completely
- [ ] [**Webhooks**](/docs/guides/webhooks/) — react to `user.created`, `user.verification.succeeded`, `session.compromised`, and password-reset events instead of polling
- [ ] [**Rate limits**](/docs/reference/rate-limits/) — what applies to your backend's Core API calls
- [ ] [**Token claims**](/docs/reference/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](/docs/reference/idp-api/) — the OIDC/OAuth runtime endpoints (authorize, token, userinfo, logout)
- [Users — Core API](/docs/reference/core-api/users/) — read and manage user records from your backend
- [Sessions — Core API](/docs/reference/core-api/sessions/) — list and revoke sessions
- [Token claims](/docs/reference/token-claims/) — every claim in a user token
- [OIDC compliance](/docs/reference/oidc/) — discovery, supported flows, and standards conformance