Sign in with lemma.id
Passwordless login.
No user data to store.
Passkey sign-in with a stable account ID that's private to your site. No emails, no passwords, no password resets, nothing to breach. Free for login.
Built for any site that just needs login. Apps, tools, communities, marketplaces, anywhere you want returning users without collecting emails, phone numbers, or passwords first.
What sign-in looks like
A visitor clicks Sign in with lemma.id and approves a passkey. Your backend gets a signed proof carrying a stable ID that only your site ever sees. That ID is their account key: no signup form, no verification email, no password reset flow, ever. The same person gets the same ID on every return visit.
Why developers pick it
What other sign-in systems can't give you
It's not just passwordless. It changes what your servers have to hold and who sits in your login path.
Nothing to breach
Your user table is one opaque ID per account. No emails, no phone numbers, no password hashes. A database leak exposes identifiers that mean nothing anywhere else.
Private by structure
Every site gets a different ID for the same person, so users can't be correlated across sites. lemma.id can't profile your users or sell ads against them, because it never learns who they are.
Not in your login path
Your backend verifies proofs locally with an open verifier library. No API key to provision, no per-login call to lemma.id, and your account records stay yours.
One integration, room to grow
Start with free sign-in. Step up when a ban has to stick.
Login is free and covers most sites. When new-account rotation becomes the attack, require a human proof on the same integration, and the same account ID, without migrating anyone.
Passkey sign-in · free
Passwordless login with a stable, site-private account ID. The same person returns as the same ID every time. This is the default, and it's all most sites need. It doesn't stop someone from making another account, since anyone can create another lemma.id.
Presence proof
A fresh passkey at presentation signing shows the holder is at the device right now. Use it on sensitive actions like payouts or deletions, without adding OTP codes.
Human proof
One account per verified human, same account ID. When you ban someone, coming back means passing identity verification again. Add it per action when abuse shows up; nothing about your login changes.
For your users
One lemma.id works everywhere. No account per site.
Users create a lemma.id once, secured by their device passkeys, and sign in to every lemma.id-enabled site with it. Each site sees a different ID, so there's no profile following them across the web, and no company that can sell ads against their logins.
Why teams choose lemma.id
Compare it to the sign-in you'd build instead
Every login option makes you custodian of something: passwords, emails, or a big provider's shared user ID. Sign in with lemma.id is the option where there's nothing to hold.
| Sign in with lemma.id | Google / social SSO | Email + password | |
|---|---|---|---|
| Your servers store | One site-private ID per user | Email, name, shared sub |
Emails, password hashes, reset tokens |
| Who sees your users' logins | No one. Verification runs on your servers | The identity provider, on every login | Only you, but you hold the secrets |
| Cross-site tracking | Different ID per site, nothing to correlate | Same identity across every app | Email reused everywhere |
| Signup friction | One passkey approval, no form | OAuth redirect + consent screen | Form, verification email, password rules |
| Ban survives rotation requires human proofs |
Step up to one account per verified human | Attacker rotates email or OAuth account | Attacker rotates emails |
How it works
Drop in, approve, verify
One script tag on the front end, one verifier library on your backend. lemma.id is not in the request path after that.
Drop in the button
Add the <lemma-signin> element with your hostname as the site ID. No registration, no API key, no dashboard step.
User approves a passkey
First-time visitors get a lemma.id in the popup; returning users just confirm. Either way your page receives a signed presentation.
Verify on your backend
The open verifier library checks the proof locally and hands you a stable, site-private ID. Use it as your account key and issue your own session.
Your login stack today
Signup form → verification email → password database → reset flows → OTP codes for anything risky → a breach target you maintain forever
With Sign in with lemma.id
Passkey approval → site-private account ID → local verification → step up to presence or human proofs where it matters → nothing sensitive to store
Verifiable audit stamps
Prove a verified human did it, later
Stamp a checkout, post, or moderation call with an offline-verifiable proof. Evidence stays in your systems, re-check years later without calling lemma.id.
Stamp at the action
The SDK's stamp() helper attaches a signed credential to any event your backend records.
Verify offline
Same local verifier you use at signup. No network call on audit review day.
Your data, your systems
lemma.id doesn't store your logs. Useful for chargebacks, regulators, and “human or agent?” questions.
Developer integration
Sign-in in one element
The drop-in button handles the popup, the passkey, and the proof. Your backend verifies the presentation locally and uses the site-private ID as the account key. Need finer control? The SDK exposes the same flow with requiredAssurance: 'passkey'.
<script src="https://lemma.id/sdk/proof-verifier.js"></script>
<script src="https://lemma.id/sdk/lemma-signin.js"></script>
<lemma-signin site-id="app.example.com"></lemma-signin>
<script>
document.querySelector('lemma-signin')
.addEventListener('lemma-signin-success', async ({ detail }) => {
// detail.presentation → verify server-side, then issue your session
await fetch('/api/login', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ presentation: detail.presentation }),
});
});
</script>
Product boundaries
What lemma.id is not
Honest edges. It replaces the password and the signup form, not your whole account system.
Not a global identity
Every site gets its own ID for the same person. No shared identifier follows people across the web, by design.
Not a contact channel
You get an account key, not an email address. If your product needs to reach users, ask for contact info separately, and only when you actually need it.
Not bot detection
Finding suspicious behavior is still your fraud stack's job. lemma.id makes the consequence stick once you've decided, if you step up to human proofs.
Add Sign in with lemma.id
Passwordless login your users can't lose and you don't have to protect. A script tag and a backend check, free.