Choose sign-in methods
Choose how people enter your tenant, then decide who may create an account and when a second factor is required. These are separate settings. Your application's OAuth integration stays the same when you change the hosted sign-in methods.
If you have not connected an application yet, complete your first sign-in before customizing the experience.
Choose the entry methods
| Method | What the person uses | What to configure |
|---|---|---|
| Password | Email or username and a password | The login identifier in Settings → Sign-up, and password policy in Security |
| Email sign-in code | A code delivered to their inbox | Email delivery and the email-code switch; see passwordless sign-in |
| Email sign-in link | A link delivered to their inbox, followed by confirmation | Email delivery and the email-link switch; see passwordless sign-in |
| Social sign-in | An account at an external provider | An enabled connector under Providers and the social switch; see social login |
| Passkey | A passkey in a password manager, device, or security key | The passkey switch; people add passkeys from their account page; see passkeys |
In your tenant's dashboard, open Security → Sign-in methods, select the methods you intend to offer, and choose Save sign-in methods. At least one method other than passkeys must remain enabled, because a person who loses their passkeys recovers the account with one of the others. With open sign-up, passkeys on, and password or email sign-in on, the sign-up page also offers creating an account with only a passkey. Check that your test account can actually use it: an enabled social switch still needs a configured provider, and email methods depend on working delivery.
For a passwordless experience, follow the passwordless configuration guide. It owns the method-switch API and its partial-update behavior.
Email codes and links sign in existing eligible accounts; they do not create an account for a new address. Before disabling passwords, choose your account-creation path.
Decide who can create an account
Open Settings → Sign-up → Self-serve sign-up to choose open, closed, or waitlisted registration. Turning on a sign-in method does not make registration open. Closed and waitlisted modes admit new accounts only through valid waitlist invitations or an administrator creating them. Follow the waitlist guide to collect requests, approve invitations, and open access in stages. Check your intended policy with both an existing account and a new person.
An open tenant can also set an optional new-account limit per UTC month or day. Past it, new sign-ups by any method are refused until the period resets, while everyone who already has an account keeps signing in.
Social sign-in has its own account-matching and provisioning rules. Read how an account is matched before connecting an existing user directory. For additional information collected at registration, use sign-up fields.
Your app can start the authorization flow at sign-up. See
start at sign-up instead of sign-in
for prompt=create and the BFF's explicit forwarding configuration.
Add the second factor
Set Security → Sign-in methods → Two-step sign-in independently of the entry methods. The MFA guide explains optional, required, and off policies, authenticator enrollment, and recovery codes.
A passkey can also answer the two-step challenge, and a passkey the person unlocks with a fingerprint, face, or PIN counts as both steps on its own; see how passkeys fit with two-step sign-in.
An email sign-in code is an entry method; it does not replace an enrolled MFA factor. Read the MFA policy before changing it for existing users: setting it to off does not bypass factors they already enrolled.
Verify the whole journey
Before inviting users, test the experience in a signed-out browser:
Sign in through each enabled method and return to the registered callback.
Attempt registration with a new account under the intended sign-up policy.
Exercise MFA enrollment, challenge, and recovery where they apply.
Confirm that a disabled method is unavailable.
Sign out and verify the session behavior your app promises.
Use troubleshooting at the first failing step, then work through the production checklist.
Last verified 2026-11-12.