Sign-in via Koder ID

Step diagram

1. 1

   User taps KoderSignInButton

   User

   From a guest screen, an auth-gated screen, or the account menu.

   ↓
2. 2

   SDK opens OIDC authorize

   SDK

   Build the authorize URL with PKCE and the registered redirect_uri; open the system browser (or in-app tab on mobile).

   ↓
3. 3

   Server resolves the identifier

   Server

   Bare username expands to <local>@<tenant_default_domain>; an explicit @ is literal; fallback to handle if email lookup fails. Timing-safe.

   specs/identity/login-resolution.kmd

   ↓
4. 4

   User authenticates

   User

   Password, passkey, or already-signed-in cookie. May require email confirmation if the account is fresh.

   ↓
5. 5

   Server redirects with code

   Server

   Browser hits /auth/callback?code=...&state=...; SDK validates state, exchanges the code for tokens.

   ↓
6. 6

   App receives the user object

   App

   Tokens persist in the platform secure store; the original screen rebuilds with the new auth context.

Common pitfalls

• ⚠ Storing the access token in localStorage instead of the platform secure store — leaks across origins on shared devices.
• ⚠ Skipping state validation on the callback — opens the door to CSRF on the auth code.
• ⚠ Sending the OIDC redirect to a non-canonical host (app.<produto>.koder.dev) — breaks every callback that was registered for <produto>.koder.dev.

Related flows