Single sign-on
Sign your people in with your own identity provider, over SAML or OpenID Connect, with new colleagues joining on their first sign-in.
On the Business plan, an organisation can sign its people in through its own identity provider: Okta, Microsoft Entra ID, Google Workspace, JumpCloud, or anything else that speaks SAML 2.0 or OpenID Connect. Everyone else keeps signing in with Google or GitHub.
SSO works for the email domains your organisation has verified, so the first step is proving you own the domain.
1. Verify your domain
In the organisation’s settings, under Verified domains, add your domain (acme.com). featflags gives you a DNS record to add:
acme.com. TXT "featflags-verification=…"Once it’s in your DNS, choose Verify. featflags checks the record again every week; if it disappears, the domain stops being verified and the owners get an email.
A verified domain also lets people with an address there join the organisation as readers on their own, without an invite: the app offers it to them when they sign in.
2. Connect your identity provider
Owners set SSO up under Single sign-on in the organisation’s settings.
SAML. Create an application in your identity provider with the values the page shows:
| Field in your identity provider | Value |
|---|---|
| ACS URL (reply URL) | https://app.featflags.io/sso/api/oauth/saml |
| Entity ID (audience) | https://app.featflags.io/sso |
| Service provider metadata | https://app.featflags.io/sso/.well-known/sp-metadata |
The application must send the user’s email address. Then give featflags your identity provider’s metadata, as its URL or by pasting the XML. featflags reads a metadata URL when you save; if your provider’s certificate changes, save it again.
OpenID Connect. Create a web application with the redirect URI https://app.featflags.io/sso/api/oauth/oidc, then give featflags its issuer URL, client ID and client secret.
Saving a new connection replaces the old one only once the new one checks out, so a typo never locks anyone out.
3. Choose who gets in
- Default role: the role people get when SSO brings them in for the first time: reader, writer or admin. Reader is the default. Owners can change anyone’s role afterwards, and later sign-ins don’t change it.
- Enforce SSO: makes SSO the only way in for addresses at your verified domains. Google or GitHub sign-ins with those addresses are refused, except for the organisation’s owners, so a broken identity provider or an expired certificate never locks you out of your own settings.
Enforcing doesn’t sign anyone out: sessions opened before it last until they expire, and API tokens keep working, since they aren’t sign-ins.
Signing in
On the sign-in screen, Sign in with SSO asks for a work email and sends the person to your identity provider. Your settings page also shows a sign-in link that goes straight to your organisation’s provider, for people whose email doesn’t say which organisation they belong to, or for a tile in your provider’s app portal.
Someone signing in for the first time joins the organisation with the default role: there’s nothing to provision in advance. Removing someone in your identity provider stops their next SSO sign-in; to take away their access in featflags at once, remove them from the organisation as well, which also revokes the API tokens they made there.
featflags trusts an email from your identity provider only at a domain your organisation has verified. That’s what stops another organisation’s identity provider from signing in your people.
Plans
SSO is on Business. If the organisation moves to a smaller plan, a connection that’s set up keeps working, and owners can still turn it off; only setting up a new one needs Business again. Sign-ins through SSO, refused ones included, appear in the audit log.