# The sign-in portal

> The hosted sign-in screen your users see, the providers you can offer, and how it is branded.

When your app has sign-in, your users log in through a hosted portal that Vaulter runs and secures. You never build, patch, or worry about a login system.

## What your users see

When someone hits "Sign in" in your app, a small window opens with your app's sign-in screen: your app's logo, a "Sign in to {your app}" heading, and the sign-in choices you have enabled. They sign in, the window closes, and they are back in your app, signed in. No redirects that lose their place, no separate site to understand.

- **Email one-time code** is a two-step flow: enter your email, then type the 6-digit code from the message. No passwords exist in this flow at all.
- **Google, Microsoft, and GitHub** are one click, using the provider's own secure window.

## Why a hosted portal

The portal handles the details that are easy to get wrong when rolled by hand: secure session handling, code expiry, provider quirks, and keeping people signed in across visits. It is the same battle-tested surface for every Vaulter app, which means fixes and hardening reach your app without you shipping anything.

## Branding

The portal shows your app's own logo and name, taken from your app's branding, so signing in feels like part of your product. You can see exactly how it looks in the live sign-in preview inside **Vault → Auth**, which mirrors the real portal as you change settings.

## One account across Vaulter apps

End users sign in with the same identity across apps built on Vaulter: if someone has used another Vaulter app with the same email, they will not have to create a new account from scratch for yours. What they can access is strictly separated per app. Signing in to your app makes them a member of your app only, and [data privacy](/docs/data/data-privacy) is enforced per app and per user. Membership respects your [registration rules](/docs/auth/add-sign-in): invite-only and domain-restricted apps still turn away anyone who does not qualify.

## A safety net at publish

Publishing checks that your app's sign-in surface and its account system agree. If your app has a sign-in page but accounts are not ready to back it, the publish stops with a clear message instead of letting a decorative login button ship. You will rarely see this; it exists so your users never can.

## How it fits together

- Providers, registration rules, and user management: [Add sign-in to your app](/docs/auth/add-sign-in).
- Requiring sign-in for the whole app: [Public vs private apps](/docs/auth/public-vs-private).
- What signed-in users can see: [How data privacy works](/docs/data/data-privacy).