What Ave can see
Each app and identity pair has its own isolated keys. Keys for one app cannot be requested by another, and different identities of the same account have different keys.
Master key
Every Ave account has a master key that encrypts all of its app keys. It is created in the browser and stored on Ave only as ciphertext. When a passkey supports PRF, the PRF output encrypts and unlocks the master key in the browser. PRF output is omitted from every credential sent to the API for registration, sign-in, and key unlocking. Recovery codes and approval from another signed-in device can also restore the master key on a new device. Saved browser master keys are associated with the account’s authenticated identities. Sign-in prefers the key unlocked by the verified passkey; a key from another account cannot substitute for it. Previously saved keys without an account association are reused only after they successfully decrypt an existing key for the current identity. Unmatched keys remain available for recovery. Passkey and recovery-code responses identify the account that owns the recovered key, and Ave checks that association before saving it. Device approval applies the session returned with the transferred key. When persistent browser storage is unavailable, an unlocked key remains available for the current page session.Key lifecycle
1
Provisioning
The first time an identity authorizes your app with an encryption scope, the Ave sign-in page generates the key material in the browser: an AES-256 key for
e2ee:symmetric, or a P-256 keypair for e2ee:asymmetric. It encrypts the secret part with the master key and sends only the ciphertext, plus the public key in asymmetric mode, with the authorization.2
Storage
Ave stores the wrapped key on the authorization record for that app and identity.
3
Delivery
On every sign-in, the Ave sign-in page fetches the wrapped key, decrypts it with the master key on the device, and appends the plaintext to your callback URL fragment. Browsers do not send fragments in HTTP requests, so the key reaches your client code without passing through Ave’s API or your server. The token endpoint never returns key material.
4
Use
Your client reads the key from the fragment, removes it from the address bar, and keeps it in client-side storage. See End-to-end encryption for the SDK helpers.
5
Rotation
When your app requests
e2ee:reset, the sign-in page generates new keys and delivers them together with the previous ones. Your app re-encrypts existing data and then discards the previous keys.6
Revocation
When a user disconnects your app in Ave, its tokens and wrapped keys for that identity are deleted. Data you encrypted with those keys can no longer be decrypted unless your app kept its own copy of the key.
Fragment hygiene
URL fragments stay out of HTTP requests, but they remain in the address bar, browser history, and anything that readslocation.href. Read the fragment on the callback page, then remove it:
URLSearchParams turns + into a space, which breaks base64. The SDK helpers restore it; if you parse the fragment yourself, call normalizeAppKeyBase64 or value.replace(/ /g, "+") before decoding.
Load analytics, session replay, and error reporting scripts after the fragment has been removed, or configure them to drop URL fragments.
Failure handling
Key missing on a route that requires encryption
Key missing on a route that requires encryption
Block the action and start sign-in again with the encryption scope. Do not fall back to unencrypted storage.
Decryption fails
Decryption fails
Treat it as a key-context mismatch: a different identity, or rotated keys. Do not overwrite the existing ciphertext.
The stored wrapped key no longer matches your data
The stored wrapped key no longer matches your data
If a trusted session still holds the original key, see Recover an app key.