Security best practices

E2EE key safety

Keep app keys and private keys on the client; never send them to your backend

Remove key-bearing URL fragments from the address bar immediately after parsing

Load analytics, session replay, and error reporting after the fragment is removed, or configure them to drop fragments

Normalize base64 fragments before decoding — replace (space) with +

Keep per-identity encrypted data partitions — never mix data across identities

Use a fresh random IV for every AES-GCM encryption

Request e2ee:reset only from an explicit user action

Never log raw key material

Use the embed SDK for iframe flows; it only accepts postMessage from the Ave issuer

OAuth request hardening

Always generate and verify state to prevent CSRF attacks

Always generate and verify nonce when requesting id_token

Use PKCE (S256) for every public client (SPA, mobile, desktop)

Token storage and handling

Treat access_token, access_token_jwt, and refresh_token as secrets

Prefer server-side token storage (HTTP-only cookies, encrypted session)

If browser storage is necessary, use sessionStorage over localStorage — never localStorage for refresh tokens

Rotate app sessions after a refresh or privilege change

refresh_token grants long-lived access. A leaked refresh token lets an attacker impersonate the user until it’s revoked. Store it server-side whenever possible.

ID token validation

When validating an id_token JWT received from Ave, check all of the following:

Signature valid against JWKS from the Ave OIDC discovery document ({issuer}/.well-known/jwks.json, where issuer is the issuer value from /.well-known/openid-configuration)

iss equals the issuer value from the Ave OIDC discovery document (e.g. https://aveid.net on the hosted service)

aud equals your clientId

exp is in the future

iat is recent (within an acceptable clock skew)

nonce matches the value you sent at authorization time

Reject tokens with missing or unexpected values for any of the above

Keep your service clocks synchronized (NTP). JWT validation is time-sensitive — a clock that’s off by more than a few minutes will cause false rejections or accept expired tokens.

Operational monitoring

Monitor spikes in invalid_grant errors — may indicate token replay or reuse attacks

Monitor spikes in invalid_scope errors — may indicate misconfigured clients or probing

Track refresh token failure patterns to detect stolen tokens

Rotate app credentials (clientSecret) periodically