# Single sign-on with any OIDC provider

LedgerBee speaks standard OpenID Connect, so any provider that publishes a
discovery document works — Google Workspace, Auth0, Keycloak, PingFederate, and
others. The provider-specific guides for
[Entra ID](/guides/sso/providers/entra-id) and [Okta](/guides/sso/providers/okta) are the same three
steps with that provider's screens.

## Requirements

Your provider must support:

- **Authorization Code flow with PKCE.** LedgerBee always sends `code_challenge`
  with method `S256`.
- **A discovery document** at `<issuer>/.well-known/openid-configuration`,
  reachable over public `https`, declaring an `issuer` identical to the URL you
  configure.
- **A JWKS endpoint** in that document, publishing the keys the ID token is
  signed with.
- **Client authentication** by shared secret, over either `client_secret_post`
  or `client_secret_basic`. LedgerBee reads
  `token_endpoint_auth_methods_supported` from your discovery document and uses
  whichever you advertise, preferring the first.

Private and metadata addresses are refused. LedgerBee resolves the issuer host
before every fetch and requires it to be publicly routable.

## Claims LedgerBee reads

| Claim | Use |
| --- | --- |
| `sub` or `oid` | The stable identifier a member is bound to. Selected by **Subject claim**. |
| `email` | Matched to a member, when the address is at a verified domain. |
| `preferred_username` | Used instead of `email` when the provider omits it. |
| `email_verified` | If present and `false`, the sign-in is refused. Absent is accepted. |
| `name` | The member's display name for a newly created account. |

LedgerBee requests the scopes `openid email profile` and reads nothing beyond
these claims. Group and role claims are not consumed — membership and admin
rights come from LedgerBee, or from
[SCIM provisioning](/guides/scim-provisioning).

## Register the application

1. Create an application of type **Web** or **Confidential client** with the
   **Authorization Code** grant.
2. Set its redirect URI to the value shown in the **Identity provider** section
   of the LedgerBee SSO page. Copy it with the **Copy** button — the token
   exchange sends the same value back, and the two must match byte-for-byte.
3. Generate a client secret.

## Configure the connection

Verify an email domain first, then fill in **Identity provider**:

| Field | Value |
| --- | --- |
| **Issuer URL** | The `issuer` value from your provider's discovery document |
| **Client ID** | Your application's client ID |
| **Client secret** | The generated secret |
| **Subject claim** | `sub`, unless your provider documents otherwise |

Select **Save**. Saving runs the check, and the connection goes live when your provider accepts the credentials.

## Google Workspace

Google is an OIDC provider, reached through a Google Cloud OAuth client rather
than the Workspace admin console.

1. In the [Google Cloud console](https://console.cloud.google.com/), open
   **APIs & Services → Credentials** and create an **OAuth client ID** of type
   **Web application**.
2. Add the LedgerBee redirect URI under **Authorized redirect URIs**.
3. Configure the OAuth consent screen as **Internal** so only your Workspace
   users can use it.

Use these values in LedgerBee:

| Field | Value |
| --- | --- |
| **Issuer URL** | `https://accounts.google.com` |
| **Subject claim** | `sub` |

Google's `sub` is stable per Google account. An internal consent screen is what
restricts the application to your Workspace, since the issuer is shared across
all Google accounts.

If a step fails, see [Troubleshoot SSO](/guides/sso/troubleshooting).