FedCM browser sign-in

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 when the selected identity has already approved every requested scope. First sign-in, newly requested scopes, or missing consent history opens the continuation dialog. Requests must also satisfy the app’s current scope allowlist.
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": "...",
  "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:

Try FedCM if the browser supports it
If unavailable, fall back to startPkceLogin()
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.

Start

OAuth

Frameworks

Capabilities

FedCM browser sign-in

When to use it

E2EE behavior

SDK usage

Returned data

Fallback model

​When to use it

​E2EE behavior

​SDK usage

​Returned data

​Fallback model

When to use it

E2EE behavior

SDK usage

Returned data

Fallback model