Auth overview

Auth controls how end users enter and access your app. It is app-scoped, so each app can have its own sign-in methods, policies, branding, SSO, MFA, organization access behavior, legal consent, hooks, and directory sync.

Auth tabs​

Tab	Use it for
Overview	Current Auth state, recommended next action, and core areas.
End Users	People who can sign in to the app.
Sign-in Methods	Password, email sign-in, magic links, passkeys, username, phone, and password policy.
Social Providers	Google, GitHub, Microsoft, Apple, and other provider-based login.
Enterprise SSO	SAML, OIDC, LDAP, and enterprise identity provider connections.
Security	MFA, session behavior, CAPTCHA, step-up authentication, and privileged sessions.
Branding	Hosted Auth appearance, logo, colors, message, and page copy.
Organization Access	Organization membership behavior, signup rules, and role model.
Auth Hooks	Synchronous hooks that inspect, block, or modify sensitive Auth flows.
Directory Sync	People, groups, and membership sync from enterprise directories.
Compliance	Terms, privacy policy, and consent requirements.

Recommended first Auth setup​

1. Open Sign-in Methods.
2. Enable one primary sign-in method.
3. Keep email verification enabled for real users.
4. Open Branding and add enough product identity for end users to trust the page.
5. Open Compliance if sign-up requires terms or privacy consent.
6. Invite a test user through an organization and confirm the flow.
7. Return to the Auth overview and confirm the state is no longer blocked.

Generate integration recipes​

The Auth overview includes an Integration recipes panel. Use it after the OAuth client exists and before wiring your app manually.

The panel generates:

• .env.example entries for your selected stack
• an app provider or token-introspection middleware snippet
• a protected page or API route snippet

Supported launch stacks are SvelteKit, Next.js, React, Vue, and Express API. The browser/framework snippets use public Auth settings only: Switera base URL, Connect client ID, app slug, and redirect URI. Secret app credentials stay on your backend and are not needed for hosted end-user login.

For Express API services, the generated snippet validates bearer tokens against Switera and protects a selected route. Pair that backend route with one of the browser/framework Auth SDKs in your frontend.

Auth is app-scoped​

Changing Auth settings in one app does not configure another app. Always confirm the app name in the sidebar before changing sign-in methods, provider credentials, SSO, or security policy.

What to configure first​

Use this order for most apps:

1. Sign-in Methods so users can enter the app.
2. Email so verification and recovery messages can be delivered.
3. Branding so hosted Auth feels trustworthy.
4. Organizations so access maps to customer accounts.
5. Security so MFA and sessions match the risk level.
6. Social Providers or Enterprise SSO when provider credentials are ready.
7. Hooks or Directory Sync when backend or enterprise lifecycle automation is required.

When to add advanced controls​

Add advanced controls when the app needs them:

• social login after provider credentials are ready
• SSO when selling to organizations that require identity provider login
• MFA when the app handles sensitive accounts or admin actions
• Auth Hooks when your backend must participate in login decisions
• directory sync when enterprise organizations expect automated user lifecycle management

Related pages:

• Sign-in methods
• Social login
• Enterprise SSO
• Security, MFA, and sessions