Sign In

Live demo

Live, from the library itself, at full size: scroll, hover, navigate away and back. The demo is never gated.

Install Pro

The demo above is never gated; the source is. With a key in components.json (see account), the registry serves it like any other item:

npx shadcn@latest add @moonarc-pro/sign-in

---
import SignIn from '@/components/moonarc/pro/SignIn.astro';
// your auth service's two endpoints; with the template kit, formProps({ adapter: 'custom', endpoint, success: false,
// refParam: false, carry: false, adapters: ['custom', 'demo'] }).props gives the same objects
const email = { action: '/api/auth/email', encode: 'json' as const };
const code = { action: '/api/auth/code', encode: 'json' as const };
---
<!-- The contract your service answers, for both steps:
     step one  POST email=…      JSON (fetch): 2xx { ok: true } sends the code; 429 too many tries; any other status fails.
                                 Native post: 303 to the page that renders <SignIn step="code" … />.
     step two  POST code=…       the code alone; the session (a cookie your service set in step one) says whose it is.
                                 JSON (fetch): 2xx { ok: true } signs in and the page goes to success; 4xx fails.
                                 Native post: 303 to your app, or back to the code page on a wrong code.
     Each request sends Accept: application/json; a fetch reads the status and the ok flag only, never your text. -->
<SignIn
  headline="Sign in"
  copy="We email you a six-digit code. No password."
  email={email}
  code={code}
  success="https://app.example.com/"
  resendHref="/sign-in/"
  backdrop
>
  <a slot="providers" href="/api/auth/sso">Continue with single sign-on</a>
</SignIn>

<!-- /sign-in/code/, the page step one's native post lands on (noindex): step two alone -->
<SignIn headline="Check your email" step="code" code={code} success="https://app.example.com/" resendHref="/sign-in/" />

Without a key the registry answers 401 with an upgrade message. Everything this section composes is free: otp-input, stateful-button, grid-pattern.

Props

Theming and overrides

The section reads the theme contract (shadcn's variable names with the base tokens as fallback), so a pasted theme or one --ma-brand recolours it. Its class names are the override surface and stay stable; a named slot replaces the matching prop with your own markup.

Why it is built this way

• The two steps are two forms, each with its own role="status" line present at load: step one's request carries the email, step two's the code alone. Your service keeps the session between them, usually with a cookie set in step one.
• The step change is CSS, :has() on the email form's data-state. The script moves the focus to the code field one frame later, because the button that had it is hidden. That move only ever follows the reader's own submit.
• OtpInput is one native input with maxlength, so a pasted "123-456" would keep "123-45". The script strips spaces and dashes from the pasted text before the field counts it.
• Nothing is written to storage, and only post is accepted, so the email and the code never reach a URL, the history or a log. success may be on another origin (your app); the lib writes its record only for a page on this one.
• Without JavaScript each step posts natively: step one's endpoint answers with a 303 to a page rendering step="code", step two's with a 303 to your app. The resend link goes back to step one and needs no script.
• There is no auth backend in the section, by design: an auth service you cannot audit is a liability, so the section is the front end and the request and response contract is in the usage.

Replaces: Sign-in pages (Tailwind Plus) · Login (shadcnblocks) · Auth UI OTP flows (Clerk, Supabase UI). See the migration table.

Related