Lighthouse answers two basic questions about every principal: who they are (Authentication) and what they may do (Authorization). Authentication checks in two ways. A discrete check (AuthN-D) looks at what the presenter holds at the moment they sign in, such as a credential, a passkey or a code. A continual check (AuthN-C) looks over time at whether the presenter still behaves like themselves. Every answer says which check gave it. Silicon agents duck-type as principals: the same two questions apply whether the caller is a person or code acting on their behalf.
No proprietary handshake. Every credential Lighthouse issues is a standards-track token any conformant client already understands.
Key your users on the sub claim, which is stable and unique per account. Never use email to identify a user or to grant access unless email_verified is true. Anyone can sign up with an address they do not own, and signing in never waits for verification, so an address without email_verified: true proves nothing about who holds it. Even then, a verified address proves only current control of the address, not a lasting identity: an address can later pass to a different account with a different sub. Bind durable accounts, permissions and invitations to sub, and use a verified email only for contact or a one-time check. Both claims appear in the ID token and at the userinfo endpoint when the email scope is granted, and email_verified is always a boolean.
Token-signing keys live in a hardware security module and rotate by kid with no verifier-visible outage.
TypeScript, Python, Rust, Swift, Kotlin and Go clients, generated from Lighthouse's own OpenAPI description (docs/specs/lighthouse/api-client-sdk-strategy.md) and never hand-coded against routes discovered by reading source.
Coming Soon.