Skip to content

The v1 docs follow nauthera-server's main branch and its 0.x releases on the way to 1.0, so fields and APIs can still change.

v1

Sign-in Flows

Docs version v1 (main)Nauthera is pre-1.0, in a design-partner programUpdated

These pages follow a person through the hosted sign-in UI the way they meet it: an application sends them to /authorize, they sign in, sign up, verify an address, prove a second factor or consent, and come back to the application's redirect_uri. Every screen is shown as it renders today, with its loading state and the errors it can show.

The screenshots come from nauthera-server's Storybook, one story per state, and are refreshed from it automatically. Open in Storybook under a screenshot opens the live story, where you can switch language, brand and layout.

The whole map

FlowStarts atPage
Sign in with a password/loginSign in
Replace a password at an administrator's request/change-passwordSign in
Create an account/registerSign up
Verify an address, reset a password, accept an invitationan emailed linkEmailed links
Sign in through an identity brokerthe broker's email screenBroker sign-in
Set up or prove a second factor/mfa/setup, /mfaSecond factor
Passkeys: offer, passwordless sign-in/mfa/setup, /passkeyPasskeys
Sign in through another identity providera provider buttonSocial sign-in
Consent, and connecting a device/consent, /deviceConsent and devices
Sign out/logoutSign out
Throttles, locks, expired sessions, unknown pagesany screenWhen something goes wrong

Rules every flow follows

  • The application's request travels with the user. Every screen carries the authorization request in its URL, so a detour to sign-up, a password reset or a second factor ends at the same application with the same state. Emailed links carry it too.
  • Every wait shows. A button that sends something spins and locks its form until the server answers; one click sends one request.
  • Every failure says what happened and leaves a way forward. A refusal the user can fix is a banner on the form they are on, and the form keeps what they typed. A throttle, a lapsed sign-in or a refusal with nothing to fix gets a page of its own, with an action.
  • A screen that does not know the application says to go back to it. The sign-in screen answers 404 unless its URL names a registered client, so a screen reached without one (an invitation link, a link opened on another device) ends with "To continue, go back to the app you came from and sign in there." rather than a button that goes nowhere. A flow the server finishes without an application, such as a federated sign-in that came back after it lapsed or a sign-up from a bare /register link, is sent to /return, which says the same.
Return to your app: this page can't tell which app you were signing in to
/return — where a flow that no longer names its application endsOpen in Storybook