Skip to main content
FedCM gives registered Ave apps a faster browser-native sign-in path on supported browsers, without depending on third-party cookies as the primary transport. Ave’s FedCM flow is additive:
  • Existing redirect + PKCE integrations keep working unchanged
  • FedCM is a new browser-only happy path for supported environments
  • If FedCM is unavailable, your app falls back to the normal PKCE redirect flow

​
When to use it

Use FedCM when you want browser-native account selection for web apps:
  • Chromium-based browsers with FedCM support
  • Registered Ave apps with a stable clientId
  • Apps that already use PKCE today and want a faster first step

​
E2EE behavior

FedCM works with Ave’s end-to-end encryption model too, but with an important detail:
  • Ave’s authorization UI on aveid.net is still the place that unlocks the user’s master key and prepares the plaintext app key handoff.
  • Because of that, E2EE apps use a FedCM continuation dialog rather than a fully in-page direct FedCM completion.
In practice:
  • Non-E2EE apps can complete directly in the initial FedCM exchange.
  • E2EE apps start with FedCM, then continue in an Ave dialog, and finally return the plaintext app_key through the completed FedCM assertion.

​
SDK usage

import { signIn } from "@ave-id/sdk/client";

const result = await signIn({
  clientId: "YOUR_CLIENT_ID",
  redirectUri: "https://yourapp.com/callback",
  scope: "openid profile email offline_access",
});

if (result) {
  // FedCM path resolved immediately in-page.
  // result.access_token, result.id_token, result.encryptedAppKey, ...
} else {
  // Browser fell back to the standard PKCE redirect flow.
  // The page will navigate away, then you finish with finishPkceLogin().
}
If you want FedCM only: 
import { signInWithFedCm } from "@ave-id/sdk/client";

const tokens = await signInWithFedCm({
  clientId: "YOUR_CLIENT_ID",
  redirectUri: "https://yourapp.com/callback",
  scope: "openid profile email",
});

​
Returned data

FedCM exchange returns the normal token payload. For E2EE apps, the completed FedCM result may also include app_key when the continuation dialog finished the Ave-side unlock flow: 
{
  "access_token": "...",
  "access_token_jwt": "...",
  "id_token": "...",
  "refresh_token": "...",
  "expires_in": 3600,
  "scope": "openid profile email",
  "app_key": "base64..."
}
This keeps compatibility with the current Ave E2EE model, where Ave’s authorization UI performs the key-unlock work and hands the plaintext app key to the RP.

​
Fallback model

signIn() follows this ladder:
  1. Try FedCM if the browser supports it
  2. If unavailable, fall back to startPkceLogin()
  3. Finish the fallback on your callback page with finishPkceLogin()
This keeps the migration low-risk: you are adding a faster path, not replacing the old one. For Ave Business workspace sign-in, pass organizationId to signIn() or startPkceLogin(). The SDK uses the PKCE redirect flow for that case because Ave must verify organization membership and SSO policy before issuing organization-context tokens.
Last modified on May 15, 2026