SHARED IDENTITY
Account.
The one account I use across participating zentr.dev projects, with OAuth 2.1-style PKCE handoffs.
WHAT IT IS
One account for participating zentr.dev projects.
I built Account at auth.zentr.dev so you can use one identity across participating projects. You can sign in with a registered passkey, use Google, or create an email-and-password account through Firebase Authentication, manage a profile photo, then approve a participating project to receive a short-lived zentr.dev identity token.
Sign in once
Open auth.zentr.dev and use Google or email and password. After signing in, add a passkey from the account page. Next time, choose Sign in with a passkey and verify with your fingerprint, face, device PIN, or security key. Email accounts receive a verification message.
Make it yours
Use a Google profile photo or upload a JPEG, PNG, or WebP image up to 5 MB. Uploaded images are resized, cropped, and stripped of embedded metadata.
Approve a project
A registered zentr.dev project sends you to the authorization page with its callback URL, state, nonce, and PKCE challenge.
Return safely
After approval, Account returns a single-use authorization code. The project exchanges it with the matching PKCE verifier for signed ID and access tokens.
INTEGRATION
OAuth-style discovery at the edge.
Participating projects can read the OpenID discovery document and public signing keys instead of hard-coding endpoints. Clients must be registered with an exact callback URL and use the authorization-code flow with S256 PKCE.
https://auth.zentr.dev
$ discovery
https://auth.zentr.dev/.well-known/openid-configuration
$ public keys
https://auth.zentr.dev/.well-known/jwks.json
ARCHITECTURE & PRIVACY
Firebase identity, zentr.dev authorization.
| Part | Behavior |
|---|---|
| Account credentials | I use Firebase Authentication for Google and email/password sign-in. I do not store passwords in D1. |
| Passkeys | Add and remove passkeys from the account page within five minutes of signing in. Keep Google or email access as a backup. Cloudflare D1 stores public keys, names, counters, and a profile snapshot; private keys and biometrics remain with your authenticator. Removing a passkey revokes its sessions. Administrators disabling or deleting users directly in Firebase must also revoke their passkeys in D1. |
| User space | When you sign in, I provision private account space, including a reserved area that participating services can use later. It is keyed to the stable Firebase account ID rather than an email address. |
| Profile photos | I normalize custom photos to a metadata-free 512-pixel WebP. Account photo requests require a valid Firebase or passkey session, and photo-service failures do not block sign-in. |
| Authorization codes | I store hashed, single-use codes in Cloudflare D1 with client, callback, scope, and profile claims. Codes expire after five minutes. |
| Tokens | My edge service signs ES256 identity and access tokens that expire after fifteen minutes. Public verification keys are exposed through JWKS. |
| Browser storage | Firebase maintains Google/email sessions. Passkey sessions use a secure HttpOnly cookie and expire after one hour. Custom profile photos are loaded into a temporary browser object URL while the account page is open. |
| Third parties | Firebase and Google process sign-in traffic. Cloudflare delivers the site and API. Google Fonts supplies the interface typefaces, so those providers receive ordinary connection metadata. |
| Account deletion | Sign in recently with Google or email to delete your account. The account page removes passkeys, their sessions, and private account space before requesting deletion of the Firebase user. |
CURRENT SCOPE
I use Account for central login and authorization. Each participating project decides how to use that identity. One account is plenty; I already have enough subdomains.