Designing sign-in

Part 3 of the visual dashboard tour. These four screens control how people get into your app — which sign-in methods you offer, which social and enterprise logins you connect, how the login page looks, and any custom rules that run during sign-up. This is the part most businesses spend the most time on, and none of it needs code.

Authentication — the sign-in methods

Open Authentication. This is a menu of every way a person can prove who they are. Turn one on, and it appears on your login page.

Flip a toggle to switch a method on, then click its gear to fine-tune it:

• Password, Email code, Magic link, Passkeys (fingerprint / Face ID), SMS code, and wallet-based options like Ethereum, Solana and Farcaster.

• QR cross-device sign-in lets someone approve a login on their computer by scanning a code with their already-signed-in phone.

The tabs across the top go deeper: Passwords & MFA (password strength rules and whether two-factor is optional or required), Sessions (how long someone stays signed in), Sign-up (what you ask for when someone registers), and Developer. There's also enterprise Kerberos / Integrated Windows Auth further down for corporate networks.

> A note on sessions. Under Passwords & MFA → Sessions you decide how long a login lasts before Atlas asks the person to sign in again. Longer is more convenient; shorter is more secure. The default is sensible — only change it if you have a reason.

Connections — social and enterprise logins

Open Connections. Where Authentication is about methods, Connections is about other identity providers you trust — "Sign in with Google," "Sign in with Microsoft," or a big customer's corporate SSO.

The tabs group the kinds of connection:

• Social login — a grid of consumer and developer providers (Google, Apple, GitHub, Microsoft and many more). Click Set up on one, paste the two values that provider gives you, and it's live.

• Enterprise SSO — connect a customer's corporate identity provider (Okta, Entra, etc.) so their staff sign in with their work login.

• SCIM provisioning — let a customer's IT team automatically create and deactivate accounts as staff join and leave.

• SAML IdP, LDAP / AD, and External JWT cover the remaining enterprise patterns.

You only switch on what you need. Most products start with one or two social logins and add enterprise options when a big customer asks.

Branding — how your login page looks

Open Branding. This is a visual editor for your hosted sign-in page and the emails Atlas sends — your logo, colours, fonts and layout, with a live preview.

• Pick a starting template (Minimal, Midnight, Bold, Enterprise) and adjust from there. Your providers, fields and any custom code are kept — only the styling changes.

• The Live preview on the right shows the real rendered page, and you can flip between Sign in / Sign up and Desktop / Mobile.

• The tabs cover the Login page, an embeddable Login widget, your transactional Emails and SMS, and Translations for other languages.

• Your sign-in page has a real address you can Copy URL and share. To serve it from your own web address (like login.yourcompany.com) instead of the shared one, use Connect a domain — covered in the Developer tools part of this tour.

Actions — custom rules during sign-in

Open Actions. This is the one screen with a slightly technical flavour, but it's worth knowing exists even if an engineer sets it up. Actions let you run a small piece of logic at specific moments in the sign-in journey.

Each flow is a point in the pipeline — for example Before sign-up (screen out unwanted registrations) or After sign-up (welcome the user, tag them, notify another system). Actions run in order, safely sandboxed, and a failure stops the sign-in rather than letting something slip through. As a non-developer, you mostly read this screen to understand what custom behaviour is in place; your engineer adds the actions.

That's the sign-in experience. Next: deciding who can do what →