The big picture
Ave combines several things that usually live in separate systems:Passwordless identity
Users authenticate with a passkey — no passwords, no SMS codes.
OAuth 2.0 + OIDC
Standard authorization code flow with PKCE, ID tokens, access tokens, and refresh tokens.
Connector delegation
One app can request scoped access to another app’s resources on a user’s behalf.
Signing
Apps can request cryptographic approval from a user — the user signs a payload with their Ed25519 key.
E2EE key delivery
Per-app, per-identity encryption keys are delivered via URL fragment (
#app_key=...) on the OAuth callback redirect — never in /api/oauth/token responses. The server never holds plaintext.The standard OAuth flow
Your app redirects the user to Ave
You construct a URL to
https://aveid.net/signin with your client_id, redirect_uri, scopes, PKCE challenge, state, and nonce. The user is sent there.The user authenticates
The user completes passkey login and selects an identity in the Ave UI. Ave issues a short-lived, one-time authorization code.
Ave redirects back with a code
Ave redirects to your
redirect_uri with ?code=...&state=.... Your app validates state before doing anything else.Your app exchanges the code for tokens
Your app (or server) sends the code to
POST https://api.aveid.net/api/oauth/token. You get back access tokens, an ID token, and optionally a refresh token.Optional extension flows
Connector delegation — app-to-app access
Connector delegation — app-to-app access
The Connector flow lets one app (“source”) request delegated access to a resource owned by another app (“target”). The user approves once at
https://aveid.net/connect. Afterward, the source app uses a token-exchange grant to get a delegated token scoped to that resource.Use this when: your app needs to act on a user’s behalf in another service that also uses Ave.→ Full guideSigning — cryptographic user approval
Signing — cryptographic user approval
Your server creates a signing request with a human-readable payload. The user sees the payload in the Ave UI and approves with their passkey. Ave returns an Ed25519 signature that you verify server-side before taking any irreversible action.Use this when: you need high-integrity proof that a specific person approved a specific action (e.g. financial transactions, permissions changes).→ Full guide
E2EE — per-app encryption keys
E2EE — per-app encryption keys
For apps that store encrypted user data, Ave can deliver a per-app, per-identity encryption key. During the authorization consent step, the Ave UI decrypts the server-stored key using the user’s master key and passes the plaintext key as
#app_key=... in the callback redirect fragment. Your server never sees plaintext key material.Use this when: you want users to own their data and you want to guarantee you can’t read it.→ Full guideTrust model
| Layer | Who operates it | What it’s responsible for |
|---|---|---|
| Ave auth UI + identity system | Ave | Passkey auth, identity selection, user consent |
| Ave API | Ave | Token issuance, validation, signing, metadata |
| Your backend | You | Session management, business logic, app-level authorization |
Ave tokens and signatures are identity signals — they tell you who the user is and what they approved. Enforcing what that identity is allowed to do in your app is still your responsibility.