Enterprise SSO

Let users sign in to Fob through your company's identity provider, such as Okta, Entra ID or Google Workspace, so they don't need a separate Fob password.

Users type their work email on Fob's sign-in page and are sent to your identity provider. They come back signed in to your apps. Fob creates their account the first time they sign in this way.

Permission

Needs Change sign-in, branding, domains and keys.

Before you begin

Verify your company's email domain, such as acme.com, on Settings > Domains, with Used for set to Email. See Email domains.

Connect Okta

1. In Fob, open Security > Identity providers, choose Add identity provider, name it Okta and choose OpenID Connect.

2. Enter your Okta issuer, such as https://acme.okta.com. Fob shows the redirect URI for this identity provider:

   https://acme.fobauth.com/sso/callback/<connection-id>

3. In the Okta Admin Console, create an app integration with OIDC - OpenID Connect and Web Application. Add Fob's redirect URI as a sign-in redirect URI.

4. Copy the app's client ID and client secret into Fob.

5. Choose your email domains and save.

Connect Entra ID

1. In Fob, add an identity provider named Entra ID with OpenID Connect.
2. Enter the issuer https://login.microsoftonline.com/<tenant-id>/v2.0, using your directory (tenant) ID.
3. In the Microsoft Entra admin center, open App registrations and register a new app. Add Fob's redirect URI as a Web redirect URI.
4. Create a client secret under Certificates & secrets, then copy the app's client ID and the secret into Fob.
5. Choose your email domains and turn on Trust email addresses. Entra ID doesn't send email_verified, so without it first sign-ins are refused. See Trust email addresses.

Connect Google Workspace

1. In Fob, add an identity provider named Google with OpenID Connect, and enter the issuer https://accounts.google.com.
2. In the Google Cloud console, create an OAuth client ID of type Web application. Add Fob's redirect URI as an authorized redirect URI.
3. Copy the client ID and client secret into Fob, choose your email domains and save.

Connect another provider

Any provider that supports OpenID Connect or SAML 2.0 works.

OpenID Connect: enter the provider's issuer. At the provider, create a web app with a client secret and Fob's redirect URI. Then copy its client ID and secret into Fob.

SAML:

1. Add an identity provider with SAML and paste the provider's metadata XML.
2. Turn on Trust email addresses. SAML has no way to mark an email as verified, so without it first sign-ins are refused.
3. Give the provider Fob's details, shown after you add the identity provider and under Service provider details in its menu. Most providers only need the metadata URL.

Detail	Value
Metadata URL	https://acme.fobauth.com/sso/saml/<connection-id>/metadata
Entity ID (audience)	https://acme.fobauth.com/sso/saml/<connection-id>
ACS URL	https://acme.fobauth.com/sso/saml/<connection-id>/acs

Warning

Turn off assertion encryption at the provider. Fob refuses encrypted assertions. Users must also start from Fob's sign-in page: Fob refuses sign-ins that start at the provider.

If you use a custom domain, some of these URLs change when you make it primary. See Custom domains.

Settings

Setting	What it does
Name	Shown on the sign-in page as Continue with name.
Email domains	The verified email domains whose users sign in through this provider.
Require name for these domains	On by default. Users on these domains can only sign in through the provider, not with a password, and can't be invited with a password.
Trust email addresses	Off by default. See below.
Provider does multi-factor	Off by default. When on, Fob counts the provider's sign-in as MFA and doesn't ask for its own second factor.
Turn off (menu)	Stops offering and requiring the provider, without deleting it.
Delete (menu)	Removes the provider and ends the sessions that came through it.

The protocol can't be changed after you add an identity provider. If two identity providers share a domain, Fob uses the older one.

Trust email addresses

When this is on, Fob treats every email address the provider sends as verified. That's how Fob links a provider sign-in to an existing user with the same email.

Warning

Only turn this on if users can't choose or change their own email address at the provider. Otherwise someone could set their address to a colleague's and sign in to Fob as them.

What happens at sign-in

When a user types an email on a domain with an identity provider, Fob offers Continue with name. If the provider is required, that's the only option.

The first time someone signs in through the provider:

• If a user already has that email, Fob links their account to the provider. Their email must have been confirmed, unless they're invited and haven't set up a password or passkey yet.
• Otherwise Fob creates a new user with the email and name from the provider.

After that, Fob finds the user by the provider's ID for them, not by email. Later changes to their name or email at the provider aren't copied to Fob. To keep users in sync, and to disable them when they leave, use SCIM.

Users can't change their email to one on a domain that has an identity provider.

Fob's own second factor still applies after a provider sign-in, the same as after a password. To skip it, turn on Provider does multi-factor, or use an OpenID Connect provider that sends mfa in amr.

Changing the issuer or entity ID

If you change an identity provider's issuer, or paste metadata with a different entityID, Fob treats it as a new provider. Each user is linked again by email the next time they sign in.

Admin sign-in

To make admins sign in to the Fob console through your identity provider, see Admins and roles.

Protocol requirements

OpenID Connect

• Fob uses the authorization code flow with PKCE, state and nonce. It asks for openid email profile, sends the typed email as login_hint, and authenticates with client_secret_basic.
• The issuer and the URLs in its discovery document must be https on public hostnames.
• The ID token must be signed with RS256, ES256, PS256 or EdDSA, have the client ID as audience (and as azp if there are several audiences), and have an iat from the last 10 minutes. Fob allows 60 seconds of clock skew.
• If the provider sends iss with its response (RFC 9207), it must match the issuer.
• A sign-in must come back within 10 minutes, in the same browser.

Claim	Used for
sub	The user's identity at this provider
email	Required on first sign-in, to link or create the user
email_verified	true is accepted, false is refused, missing needs Trust email addresses
name, given_name, family_name	The new user's name
amr	Passed on in Fob's tokens. mfa counts as Fob's second factor.

SAML

• Fob sends an unsigned AuthnRequest over HTTP-Redirect, asking for an emailAddress NameID. The response must come back by HTTP-POST to the ACS URL within 10 minutes.
• The response must hold one unencrypted assertion for Fob's entity ID. The response, the assertion or both must be signed with RSA and SHA-256, SHA-384 or SHA-512, using a certificate from the metadata. Fob allows 3 minutes of clock skew.
• The metadata needs an entityID, an HTTP-Redirect SingleSignOnService on https, and at least one signing certificate with an RSA key of 2048 bits or more. Fob keeps up to eight, so the provider can publish its next certificate before rotating.
• Metadata and responses can be up to 128 KB. XML with a DTD is refused.
• To keep the current metadata when editing, leave the field empty.

Fob reads these attributes:

Fob field	Attribute names
Email	email, mail, emailaddress, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, urn:oid:0.9.2342.19200300.100.1.3. Without one, a NameID containing @.
Name	displayName, name, or ending in /claims/name or /identity/claims/displayname
Given name	givenName, firstName, or ending in /claims/givenname
Family name	surname, lastName, sn, or ending in /claims/surname