Universal Login
Design the login.
No code. Every method.
A no-code Forms builder drives your login page — fields, steps, consent and branding. Every way to sign in, resolved per project and per organisation: passkey, password, PIN, SSO/SAML, OIDC, magic-link, social, and anti-fatigue push approval. The login surface every user touches, built as a masterpiece and hardened end to end.
Available on Pro and above. See pricing
The Forms builder
What you build is what they see.
The login page is the one surface every user touches, yet it usually ships as a forked front-end app that drifts from your brand and your policy. AuthFI inverts that: you compose the flow in a no-code builder — fields, steps, methods, consent and branding — and the same schema renders the live page. There is no second source of truth, no redeploy, and no login front-end to maintain.
- One schema, two surfaces: the steps you order on the left are the steps the user walks on the right — edit the flow, ship it instantly.
- Consent on the record: terms, privacy and marketing opt-in are captured versioned and timestamped, so the proof an audit asks for already exists.
- Policy lives in the flow: auth methods, CAPTCHA policy, rate-limit and lockout thresholds are part of the same schema, not bolted on after.
Edit the flow on the left, ship it on the right — instantly. No fork of the login app.
Fields & steps
Drag in the fields and order the steps — identifier-first, password, MFA, consent. The same schema renders the live page; no redeploy.
Branding
Logo, colours, copy, layout, custom domain. Per-project and per-org, so each tenant sees their own brand at sign-in.
Consent & terms
Versioned, timestamped consent capture — terms, privacy, marketing opt-in — proven on the record for audit.
Methods & hardening
Which auth methods are offered, the CAPTCHA policy, rate-limit and lockout thresholds — all wired into the same flow.
Every method
Every way to sign in. One flow engine.
Each method below is a different protocol — WebAuthn for passkeys, OAuth for social,
SAML 2.0 and OpenID Connect for enterprise federation — but they all resolve through
a single engine. Turn methods on per project, restrict them per organisation, and let the user
choose from what’s left. The engine computes the effective set
(project default → org override → user choice) and renders only those.
Passkeydefault
Phishing-resistant, passwordless. The default — users tap once with Face ID, Touch ID, or a security key.
Password
Classic credentials, hardened — breached-password rejection, Argon2id hashing, lockout on abuse.
PIN
A numeric knowledge factor with strict per-account lockout — never the sole factor for high-assurance.
SSO / SAML
Federate up to an organisation’s SAML IdP per connection — while AuthFI still issues tokens down to your apps.
OIDC
OpenID Connect connections to an org’s upstream provider, brokered through the project’s issuer.
Magic link
Passwordless email sign-in — a one-time link, single-use and short-lived.
Social
Google, Microsoft, Apple, GitHub and more, mapped to a real identity in your directory.
Number-matching push
Anti-fatigue push approval: the screen shows a number, the user picks the match on their device. Defeats push-bombing.
Passwordless-first by default. The passkey is the headline — a phishing-resistant WebAuthn credential — and everything else is a fallback you control.
Project = IdP, org = realm
The login knows who’s signing in.
Type an email and AuthFI routes it. The domain maps to an organisation, the org’s connection decides the method — Okta SAML for one tenant, Entra OIDC for the next — and every token is issued by the project’s own in-region issuer. There is no global login; every authentication happens in a project’s context, which is what makes one page serve every enterprise without a “which company are you with?” prompt.
- Project is the IdP: each project signs its own tokens — its own issuer, JWKS and custom domain — and is pinned to a region, so login and tokens are issued in-region for residency.
- Org-level methods: an organisation can override or restrict the method set through its connections — federate up to its own SAML / OIDC IdP, while AuthFI still issues tokens down to your apps.
- Broker & issuer in one: federate enterprise IdPs in, issue AuthFI tokens out — the inbound assertion is verified, then a fresh OIDC token is minted from the project’s issuer.
Session profiles
Standard for apps. Strict for banking.
A session is a policy boundary, not just a cookie. Pick a named session profile per project (the org can override). Standard keeps consumer apps frictionless; Strict assembles the high-assurance primitives a regulated workload needs — short TTL with idle timeout, mandatory MFA, transaction-level step-up, and no persistent sessions — so the assurance level is a setting, not a rebuild.
Standard
- Session TTL Long-lived
- Remember me Allowed
- MFA Risk-based
- Step-up On elevated risk
- Device binding Optional
Strict / banking
high assurance- Session TTL Short + idle timeout
- Remember me Disabled
- MFA Mandatory
- Step-up (SCA) Per sensitive action
- Device binding Required
Strict reuses the finance module’s SCA / PSD2 / FAPI machinery — re-authenticate per payment or role change, recorded as an elevated ACR / AMR on the resulting token.
Hardened by default
The most-touched page, the most defended.
Login is where the attacks land — credential stuffing, password spraying, push-bombing, enumeration. Every defence below is on by default and applied on every live path, not advertised and shadow-only. They are countermeasures to specific, named attack classes, not a generic “security” checkbox.
Rate-limit & throttle
Per-IP, per-account, per-project limits on login, reset, MFA and token endpoints — automated traffic never gets a clean run.
Lockout & backoff
Progressive backoff and account lockout after repeated failures, with time-based or admin unlock and notification.
Breached-password rejection
Known-breached passwords are refused at signup and reset via k-anonymity — no leaked credential is ever set.
Account-enumeration safe
Identical responses and timing for known vs unknown accounts — attackers can’t probe which emails exist.
Risk-first and invisible by default — detect-engine signals decide when to challenge, so most real users never see one. When a challenge is warranted, it is a privacy-preserving proof-of-work — no third-party beacon, no PII, no image puzzles — issued and verified server-side as a signed, single-use, time-boxed token, with difficulty that scales to the risk. Because verification is server-side, there is no third-party tracker shipped to the browser and no dependency on an external CAPTCHA vendor.
Enforced at login,signup,reset,MFA,token endpoints — per-project policy, set right in the Forms builder.
The whole surface, controlled
Build the login your users deserve.
A no-code Forms builder, every modern method, per-org realms, strict session profiles, and hardening on by default — built for banking-grade and regulated workloads. One schema owns the page, the methods, the session policy and the defences, so the login surface stays a masterpiece instead of a maintenance liability.
Get started
Ready to get started?
Free for 5,000 monthly active users. No credit card required.