> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aveid.net/llms.txt
> Use this file to discover all available pages before exploring further.

# FedCM browser sign-in

> Use Ave with the browser's FedCM account chooser for a faster sign-in path, with fallback to the standard redirect flow.

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

```ts theme={null}
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:

```ts theme={null}
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:

```json theme={null}
{
  "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:

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.