# Any OIDC provider (https://docs.fuser.studio/docs/teams/sso/oidc)

Fuser accepts any identity provider that implements **OpenID Connect** with the authorization code flow and publishes a discovery document. If yours has a dedicated guide — [Okta](https://docs.fuser.studio/docs/teams/sso/okta.md) — start there. Otherwise this page is the full contract.

## What your IdP must provide [#what-your-idp-must-provide]

### Discovery [#discovery]

Fuser fetches `<issuer>/.well-known/openid-configuration` when you register the provider, and takes the authorization, token, and userinfo endpoints from it.

The issuer must be a **public HTTPS URL**. Internal hostnames, bare IP addresses, `localhost`, and `.internal` or `.local` suffixes are rejected — the fetch happens on Fuser's servers, not in the member's browser.

### Scopes and claims [#scopes-and-claims]

Fuser requests `openid`, `email`, `profile`, and `offline_access`, and reads the standard claims:

| Fuser uses | Claim     | Required |
| ---------- | --------- | -------- |
| Account ID | `sub`     | Yes      |
| Email      | `email`   | Yes      |
| Name       | `name`    | No       |
| Avatar     | `picture` | No       |

The email address must be inside the domain you verify with Fuser, or its subdomains. A token carrying an address outside it is rejected — including for guest or federated accounts whose real address belongs to another company. Those members need an account on your verified domain, or an email invitation to Fuser.

Fuser treats `sub` as an opaque account identifier. Your IdP should keep it stable across a rename; do not map it to the email address.

All four are requested on every sign-in and the set is not configurable from the workspace settings panel, so your IdP has to permit them. `offline_access` in particular is often gated behind a separate refresh-token grant — enable it rather than trying to suppress the request, because an IdP that rejects the scope rejects the whole authorization request.

> [!NOTE] `email_verified` is not used
>
> Fuser does not read your IdP's `email_verified` claim, and there is no setting to make it authoritative. A member's address is treated as verified because the provider's domain passed DNS verification and the address is inside it — a stronger signal than a claim your IdP is free to define however it likes. You can leave the claim out.

### Flow [#flow]

Fuser uses the **authorization code flow** with a confidential client. Configure the application as a web or server-side application, not a SPA, native, or public client — Fuser authenticates to the token endpoint with a client secret.

Only **SP-initiated** sign-in is supported. Leave any "initiate login URI" or app-tile launch option empty and point members at the Fuser sign-in page.

## Set up [#set-up]

    ### Create the application in your IdP [#create-the-application-in-your-idp]

    Create a web application using the authorization code flow. Note its **client ID** and **client secret**, and your IdP's **issuer URL**.

    Leave the redirect URI as a placeholder for now — you get the real value in step 3.

    ### Register the provider in Fuser [#register-the-provider-in-fuser]

    Open **Settings** → **Workspace** → **Security** → **Single Sign-On**, choose **OIDC**, and enter your email domain, issuer, client ID, and client secret. Click **Add provider**.

    Registration fails here if the discovery document cannot be fetched — that is the check working, not a bug. See [Troubleshooting](#troubleshooting).

    ### Add the redirect URI [#add-the-redirect-uri]

    Copy **Redirect URI** from Fuser's provider card into your application's redirect URI, sign-in redirect URI, or callback URL field.

    ### Grant access [#grant-access]

    Assign the users or groups who should be able to use the application, if your IdP requires explicit assignment.

    ### Verify the domain and test [#verify-the-domain-and-test]

    Add the TXT record shown on the provider card, wait for **Verified — SSO active**, and sign in from Fuser with an address on that domain.

    See [Verifying the domain with DNS](https://docs.fuser.studio/docs/teams/sso.md#verifying-the-domain-with-dns) for the details.

## Rotating the client secret [#rotating-the-client-secret]

Fuser never shows a saved client secret again, and there is no edit control for it. To rotate: create the new secret in your IdP, remove the provider in Fuser, and add it again with the new value. Members cannot sign in during the gap, so do it out of hours.

Removing and re-adding mints new endpoint URLs and a new DNS record, so plan on re-pasting them in your IdP and verifying the domain again — see [Provider settings are final](https://docs.fuser.studio/docs/teams/sso.md#provider-settings-are-final).

## Troubleshooting [#troubleshooting]

    Fuser fetches the discovery document server-side, so the issuer has to resolve on the public internet over HTTPS. Confirm `<issuer>/.well-known/openid-configuration` returns JSON from outside your network before registering.

    The client secret is wrong, or the application is configured as a public client that does not accept a secret at the token endpoint. Switch it to a confidential web application and re-add the provider with a fresh secret.

    The value in your IdP must match Fuser's **Redirect URI** exactly, including scheme, host, path, and the absence of a trailing slash. Copy it from the provider card.

    The `email` claim carried an address outside the domain you verified. Check which attribute your IdP maps into `email` — some map a username or a UPN that does not match the member's mailbox.

    The `profile` scope is not granted to the application, so `name` and `picture` never arrive. Add it on the IdP side.

## What's Next? [#whats-next]

  - [SSO overview](https://docs.fuser.studio/docs/teams/sso.md): Domain verification, enforcement, and what members see.

  - [Any SAML provider](https://docs.fuser.studio/docs/teams/sso/saml.md): The SAML 2.0 path.