> For the complete documentation index, see [llms.txt](https://beamline.gitbook.io/beamline-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://beamline.gitbook.io/beamline-docs/guides/build-sign-in-and-sign-up-in-react.md).

# Build sign-in and sign-up in React

A complete sign-in and sign-up flow in React on any auth service: passwords, e-mailed codes, magic links, passkeys and single sign-on, validation, a bot check slot and legal links, with your handlers

> The original of this page is on beamline.io: [beamline.io/guides/react-sign-in-sign-up](https://beamline.io/guides/react-sign-in-sign-up).

By Danylo Pravda, 2026-10-11

The sign-in screen is the first thing every user of your product sees, and the place where a generated app looks most generic: two fields, a button, maybe a Google logo. Beamline has three parts for it, and none of them talks to an auth service by itself. They run on your handlers, so they work with Clerk, Auth0, Supabase, Firebase, your own API or anything else. This guide shows which part to use and what each one handles.

![The Beamline auth block: sign-in card on a dotted field with a light that follows the mouse](https://beamline.io/components/og/auth.png)

## Three parts, one decision

| you need                                                                                                | part                                                       |
| ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| the whole sign-in and sign-up route: product mark, backdrop, both cards switching in place, legal links | [Auth](https://beamline.io/components/auth)                |
| a sign-in card inside your own page, panel or modal                                                     | [Sign-in](https://beamline.io/components/sign-in)          |
| an account creation card on its own                                                                     | [Sign-up form](https://beamline.io/components/signup-form) |

The [auth](https://beamline.io/components/auth) block holds the other two: the sign-in and sign-up cards switch in place, and focus lands in the first field of the card that appears.

## Every method, on your handlers

The [sign-in](https://beamline.io/components/sign-in) card offers whichever methods you pass a handler for, and nothing else:

* e-mail and password (`onPasswordSignIn`);
* a one-time code sent by e-mail (`onRequestCode`, `onVerifyCode`);
* a magic link (`onRequestLink`);
* passkeys (`onPasskey`);
* single sign-on providers (`providers`, `onProvider`).

Integration sketch: supply your auth service and router; password sign-in and code verification return AuthAccount, while requesting a code returns void.

```tsx
import { SignIn } from "@beamline/sign-in";

<SignIn
  product="Acme"
  onPasswordSignIn={({ email, password }) => auth.signIn(email, password)} // resolves to the account
  onRequestCode={(email) => auth.sendCode(email)}
  onVerifyCode={(email, code) => auth.verifyCode(email, code)}
  providers={[
    { id: "google", label: "Google" },
    { id: "github", label: "GitHub" },
  ]}
  onProvider={(provider) => auth.redirectTo(provider.id)}
  onSuccess={(account) => router.push("/app")}
/>
```

Each handler returns a promise. When it rejects, its error shows on the card (on the field it blames, when it names one) and the person can try again. Providers are a name and an optional icon you are licensed to use; without one the button is text only.

## The details that are easy to get wrong

* **Codes need no click.** The code step focuses its [code boxes](https://beamline.io/components/otp-input), and typing or pasting every digit checks the code by itself.
* **Errors move focus.** On the sign-up form, Enter submits and the first invalid field takes focus.
* **Passwords say what is wrong while you type.** Strength and a Caps Lock hint, before the request fails.
* **The bot check has a place.** Sign-in takes a `challenge` slot: an auth service's bot check (Clerk's Turnstile box, for one) renders in the card under Continue, stays across steps and takes no room until it asks.
* **Consent is real.** The sign-up form asks for terms consent with your `termsHref` and `privacyHref`, and nothing opens without it.
* **The way back is one press.** "Use a different e-mail" returns focus to the e-mail field.

## Where this runs today

beamline.io's own sign-in is built from these parts on Clerk, with Clerk running headless behind Beamline's cards. The same cards would run on any other service: only the handlers change.

## Ask your agent for it

With Beamline connected ([setup for your agent](https://beamline.io/connect)): "a sign-in and sign-up route on Clerk with Google, GitHub and an e-mailed code, then send people to /app". The agent installs the auth block, writes the handlers around your auth service's SDK, and leaves out the methods you did not ask for.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://beamline.gitbook.io/beamline-docs/guides/build-sign-in-and-sign-up-in-react.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.