Skip to content
Torii docs

Key Components

Most Torii apps are built from a handful of components: the provider, the two auth gates, and a few drop-in surfaces. Start here, then see the components overview for the full surface (the rest of the control gates, account widgets, low-level forms, runtime status).

ComponentWhat it is
<ToriiProvider>The root provider. Wraps your app, owns session state, refreshes the access token in the background, and exposes auth to the tree via context. Every other Torii component and hook must render inside it.
<SignedIn> / <SignedOut>The auth gates. Render their children only when the user is signed in (or out), so you can swap the sign-in surface for the account surface. The full set of gates (<AuthLoading>, <Show>, redirects) lives in control components.
<SignIn>The prebuilt sign-in card: heading, email/password form, OAuth strip, and footer. The component most apps reach for.
<SignUp>The prebuilt registration card, the sign-up counterpart to <SignIn>.
<UserDashboard>A ready-made account page: a <UserButton> header plus the full <UserProfile> (profile, password, sessions, connected accounts, privacy).

Putting them together

Section titled “Putting them together”

Wrap your app once in <ToriiProvider>, then swap the sign-in surface for the account surface based on auth state with the <SignedOut> / <SignedIn> gates:

import {
  ToriiProvider,
  SignedIn,
  SignedOut,
  SignIn,
  UserDashboard,
} from '@torii-js/torii-react';


function App() {
  return (
    <ToriiProvider publishableKey={import.meta.env.VITE_TORII_PUBLISHABLE_KEY}>
      <SignedOut>
        <SignIn />
      </SignedOut>
      <SignedIn>
        <UserDashboard />
      </SignedIn>
    </ToriiProvider>
  );
}

Give <SignUp> its own route, or toggle it with <SignIn>, for registration. API base URL, OAuth providers, labels, and theme all come from <ToriiProvider> context, so the cards stay prop-light.

Next steps

Section titled “Next steps”