Passwordless authentication
for your website
Let people sign in with a one-time code emailed to them — no passwords to create, remember, store, or leak. Logintoo is an OAuth 2.0 authorization server you can self-host.
How it works: for your users
Four steps, no password anywhere in sight.
- 1
A visitor taps Log in or Sign up on your site and is sent to the Logintoo authorization server, where they enter their email address.
- 2
Logintoo emails a one-time access code to that address.
- 3
The visitor enters the code. Logintoo verifies it — proving they control the inbox — and sends them back to your site with an access token.
- 4
Your site uses the token to grant access. The user has no password to remember, and you have none to store or protect.
Single sign-on for organizations
When your user’s employer runs the directory, let them run the login.
They just type their work email
Logintoo recognizes the domain and hands them to their company’s own identity provider — Google Workspace, Microsoft Entra ID, Okta, or any OIDC provider. No new password, nothing new to learn.
Access follows the directory
Their administrator decides who may sign in, from the console they already use. Offboard someone there and they lose access here — without a ticket to you.
Nothing in your app changes
The same OAuth 2.0 redirect, the same signed token, the same code you already wrote. One claim tells you which way the user came in.
Everyone else keeps the one-time code — the two run side by side, decided per email domain. See how it works in the API.
How it works: under the hood
Standard OAuth 2.0 with PKCE — Logintoo just replaces the password with a one-time code.
Reference architecture
Three components work together:
Your API
The resource server that serves user requests. It can be serverless with API Gateway and Lambda.
Logintoo
The OAuth 2.0 authorization server that authenticates users and issues access tokens. Open source — deploy your own on AWS.
The workflow
- 1
Your site (the client) requests an access token from the authorization server, following the OAuth 2.0 and PKCE exchange in RFC 6749 and RFC 7636.
- 2
The authorization server authenticates the user by emailing and validating a one-time code, then issues an access token.
- 3
Your site calls your API (the resource server), presenting the access token — a signed JWT.
- 4
The resource server validates the token and, if valid, serves the request.
The authorization server also issues and rotates refresh tokens, used to obtain a new access token when the current one expires. A single authorization server can issue tokens for many resource servers.
Open source
Read the code, file an issue, or self-host the whole stack. It lives on GitLab.
Why passwordless?
Passwords are the weak point attackers reach for first. Remove them, and a whole class of breaches goes with them — said better by the people who study it:
In [Basic Web Application Attacks], about 88% of the breaches involve the use of stolen credentials.
Passwords can be stolen, guessed, reused, or captured through phishing.
Passwords are the weakest link in the security chain, prone to human error and vulnerable to phishing, credential stuffing, and brute force attacks.
Use of stolen credentials to access valid accounts surged 71% over the previous year and represented 30% of all incidents.
Ready to drop passwords?
Take the live demo for a spin, browse the source, or get in touch — we’d love to hear from you.