Roll out to your team

With triauth, your domain becomes the sign-in for your organization. Each member gets an identifier at your domain, such as their email address. Their devices hold their keys. Your DNS holds the public keys and decides who is in. This page walks through a rollout.

What you get

🔒 Improve security posture and meet higher compliance requirements through the use of phishing-resistant, device-based, passwordless authentication processes, reducing the risk of expensive breaches resulting from unauthorized access and ensuring integrity across all member interactions.

🔐 Oversee all members and authenticated devices by granting or revoking access in one independent and public space (DNS), for streamlined control, vendor independence, and transparency.

🔐 Improve team productivity and helpdesk efficiency by reducing the stress and time wasted on traditional authentication systems, managing password vaults, the lifecycle of employee accounts, and password reset requests.

✨ Gain full visibility, control, and auditability over the authentication process with the source code of client libraries and the authenticator application publicly available, ensuring security and trustworthiness at every step.

Plan the identifiers

• Use email addresses as identifiers, so that nobody has to learn a new name. Email and triauth records do not interfere with each other.
• For separate teams or departments, consider using subdomains, for example john@sales.example.com. Each subdomain has its own domain record, and can set its own authenticator, mode and include policy.
• The part before @ uses lowercase letters, digits, dots, and hyphens.

Choose a mode

Private mode, the default, keeps the list of your members out of DNS. Each identifier gets a lookup code at its first setup. Keep a registry of identifiers and their lookup codes. You need a lookup code to set up a member's identifier on another device, and to find their records when you remove them.

Public mode publishes identifiers in DNS. It suits organizations that want a public directory.

See Public and private mode.

Choose an authenticator

Point your domain at the authenticator hosted by the triauth project, or host your own copy at a host name under your domain. Self-hosting keeps the code that handles your members' keys under your control. See Self-host the authenticator.

example.com.   TXT   "triauth auth.example.com mode=private"

Publish the records

Each member runs the setup on each device they sign in from. The setup produces the DNS records for that device. Two ways to get them into DNS:

• Members send you the records. The setup can export them as a zone file that you import, or you copy them into your DNS panel.
• Members with access to the DNS panel publish their own records.

Ask members to verify their records in the setup, and to register at least two devices.

Add roles with groups

A groups record lists the groups a member belongs to. Websites receive the list at sign-in and at every session check, and they can map it to their own roles.

john._at.example.com.   TXT   "groups admins,billing"

Keep the record next to the member's key records. See Groups for the naming rules and what websites do with them.

Share identities with delegation

Delegation lets one identifier act for another. Several members can operate a team identity such as support@example.com, and each of them signs in with their own keys. A service or an automated agent can act for a member with keys of its own. Websites see both the account and the actor.

Publish an include record in the shared identifier's identity records. It names the actor, either with its identifier or its identity domain, and the websites the grant applies to. Delete the record to take the permission back.

support._at.example.com.   TXT   "include john@example.com scope=app.example.com"

If the actor's domain runs in private mode, write the actor as its identity domain, such as _4GIBDU53B3._at.example.com. This keeps the actor's identifier out of DNS. See Public and private mode.

Your domain's record decides who members may delegate to. The default allows actors at any domain. Set include=local to keep delegation inside your organization, or include=none to turn it off. See Delegation for the parts of the record.

Remove access

Delete the member's records from DNS. Their devices can no longer sign in anywhere, and websites that re-check sessions end their sessions at the next check. The delay depends on the record's time to live in DNS, and on how often each website checks.

For one lost device, delete only that device's records.