Why triauth
Passwords ask too much of everyone
A password is a secret you must remember, type, and protect on every website. Websites must store it, hash it, rate-limit it, and reset it. An attacker only has to trick you into typing it once.
The common alternatives move the problem to someone else. A "Sign in with a big platform" button puts one company between you and every account, and it can close your account without recourse. Corporate single sign-on works well inside one company and costs extra everywhere else.
What triauth changes
One identifier for every website
You sign in everywhere with the same identifier, for example your email address. You do not create a password anywhere. A website only needs your identifier to know who you are.
Your keys stay on your devices
Each browser you register creates its own key pair. The private key never leaves the device. There is nothing to remember, and nothing to type into a fake page.
Your domain is the source of truth
Your public keys are DNS records under your own domain. You add a device by publishing a record, and you remove one by deleting it. Every website that supports triauth sees the change at its next check. No dedicated identity provider stands between you and your accounts. As long as you control your domain and its records, nobody can lock you out of them, and nobody can sign in as you.
Nothing to run, nothing to pay per user
A website adds triauth with a library and a few lines of code. It does not run an identity server, sign contracts with identity providers, or pay per user. The authenticator is a small web application made of static files, with no backend behind it. You can use the copy that the triauth project hosts, or host your own.
How it compares
Passwords lose on every row, so the table leaves them out.
| triauth | Passkeys | "Sign in with Google or Apple" | Corporate SSO (SAML, OIDC) | Magic links and email codes | |
|---|---|---|---|---|---|
| You sign in with | Your identifier at your domain, which can be your email address | A credential stored per website | Your Google or Apple account | Your employer's identity provider | A link or code sent to your email |
| Same identity on every site | Yes | No, one credential per site | Within the platform | Within the company | Yes, your email address |
| Single sign-on for a business customer | The customer types its domain | Not covered | Only for customers on Google Workspace | Metadata exchange and setup per customer, often a paid tier | Not covered |
| Remove a lost device or person's access | Delete their DNS records, and every website that checks sessions logs them out at its next check | Delete the credential on every website, one by one | Sign the device out at the platform, or suspend the account if you manage it. Open sessions usually stay open | Deprovision the user at the provider, for the websites in the federation. Open sessions usually stay open | Disable the mailbox. Open sessions usually stay open |
| Session hijacking resistance | The website may check your DNS records at any time, and can ask your device for a fresh signature | A fresh assertion needs the user's touch. No background check | Typically no check after sign-in | Typically no check after sign-in | Typically no check after sign-in |
| What a website integrates | One library, the same for every domain | Credential management and recovery per site | One integration per platform | Per-customer setup, often a paid tier | Email delivery, bounce monitoring, and rate limits |
| Phishing resistance | Good. No secret to type, and a response works only for the website that asked | Good. Bound to the website | As strong as the account setup | As strong as the account setup | A code can be relayed |
| More than sign-in | Sign documents, prove a session to another website, collect attestations | No | No | No | No |
| Switch providers | Keep your identifier. Point your domain's record at another authenticator and set up your devices there, or move your whole zone | Move them between password managers that support the FIDO exchange format, or register again at each website | No | Set up the federation again | Move the mailbox and keep the address, if the address is at your own domain |
Passkeys are good at what they do. They are strong credentials bound to one website. Triauth solves a different problem, a portable identity you control, with sign-in and revocation that work the same on every website. The two combine well. Your triauth authenticator can also work with a passkey, a security key, a fingerprint, or a face.
Who it is for
Individuals
If you own a domain, for a personal website, for your email, or for a Bluesky handle, you already have what triauth needs. Add one DNS record, and you@example.com becomes your login on every website that supports triauth.
Developers
If you build a website or an app, triauth gives you sign-in with no passwords to store, protect, or reset, in a few lines of code with a library. Business customers get single sign-on for their staff by typing their domain. With the same keys, you can ask users to sign documents, or collect confirmations about them, such as their age, from providers you trust.
Teams and organizations
If you run a team or a company, triauth turns your domain into the sign-in for your staff. Every member gets an identifier at the company domain and uses it for your internal tools and for the services you use that support triauth. When someone leaves, you delete their records, and their access ends everywhere.
Ready? Set up your identity, or add triauth to your app.