Any OIDC provider
Connect any OpenID Connect identity provider — Auth0, Keycloak, Ping, or your own.
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 — start there. Otherwise this page is the full contract.
What your IdP must provide
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
Fuser requests openid, email, profile, and offline_access, and reads the standard claims:
| Fuser uses | Claim | Required |
|---|---|---|
| Account ID | sub | Yes |
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.
`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
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
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
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.
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
Assign the users or groups who should be able to use the application, if your IdP requires explicit assignment.
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 for the details.
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.