Session page template
patterns specs/patterns/session-page.kmd
The sign-in / session surface: a single centered card on the base shell that authenticates the user and nothing else. One primary identity action (the Koder ID / gov.br sign-in), passwordless-first, with the login-resolution rules for the identifier field, clear error copy that never says which factor was wrong, and the standard recovery links (forgot access, create account). Modeled after the gov.br Padrão Digital `sessão` template (área de login / "Entrar com gov.br").
When this pattern applies
Primary triggers
- Build the session / sign-in page of a Koder surface
All triggers
- Design a sign-in / login / session-start page
- Lay out the Entrar com gov.br / Koder ID authentication surface
- Place the identifier field, primary sign-in action, and recovery links
Specification body
Session page template
Source: gov.br Padrão Digital
sessãotemplate — the login/session surface ("Entrar com gov.br"). In the Koder Stack it composes the base shell and the form-page mechanics; it fixes what a sign-in screen contains and how it fails.
R1 — One purpose, one card
A session page SHALL present a single centered card in the base-page <main>
slot (patterns/base-page.kmd) whose only job is to authenticate. It SHALL NOT
mix in unrelated content (marketing, dashboards, settings) — one-thing-per-page.
R2 — Primary identity action
The card SHALL expose one primary sign-in action — the Koder ID sign-in
(specs/koder-app/behaviors.kmd §1 + auth/oauth-flow.kmd), rendered as the
Filled button. Federated / "Entrar com gov.br" or other providers, when offered,
SHALL be secondary actions below the primary, never competing Filled buttons.
R3 — Passwordless-first
Where the surface supports passkeys (auth/passkeys.kmd), the session page SHALL
offer the passkey path first (passwordless), falling back to password only when no
passkey is enrolled — never presenting password as the sole or default factor when
a passkey exists.
R4 — Identifier field resolution
The identifier ("E-mail") field SHALL resolve a bare username vs. a full email per
specs/identity/login-resolution.kmd — the field accepts both forms and the
resolution is server-side, not a client guess. The field carries a programmatic
label (never placeholder-as-label, per components/text-fields.kmd).
R5 — Non-revealing failure copy
A failed sign-in SHALL show one calm, non-blaming message that does not reveal
which factor was wrong or whether the account exists (per
errors/user-facing-messages.kmd + auth/oauth-flow.kmd) — e.g. "We couldn't sign
you in. Check your details and try again." No "wrong password", no "no such user".
R6 — Recovery and create paths
The card SHALL provide the standard recovery links — forgot access / reset — and,
where self-registration is allowed, a create-account path, both as descriptive
links (never "click here", per foundations/ux-writing.kmd R9).
R7 — Language floor
The session page SHALL honor the en-US + pt-BR toggle floor
(policies/language.kmd); the toggle is reachable before authenticating.
Composição
Composes base-page (shell) + form-page (the card's field/validation/submit
mechanics). This template adds only the identity-specific rules (R2–R6); it does
not re-derive form layout or the page frame.
References
meta/docs/stack/specs/patterns/base-page.kmdmeta/docs/stack/specs/patterns/form-page.kmdmeta/docs/stack/specs/koder-app/behaviors.kmdmeta/docs/stack/specs/auth/oauth-flow.kmdmeta/docs/stack/specs/auth/passkeys.kmdmeta/docs/stack/specs/identity/login-resolution.kmdmeta/docs/stack/specs/errors/user-facing-messages.kmd