Single sign-on for SecretWolf

Let your team sign in with the Microsoft 365 or Google account they already have. Available on the Business plan, set up by a workspace owner in a few minutes — and honest about what it doesn't do.

What it does

• Your team signs in with their existing work account: Microsoft Entra ID or Google Workspace, over OpenID Connect with authorisation code flow and PKCE.
• Your identity provider does the authenticating. SecretWolf never sees a password, and your multi-factor and conditional-access rules apply unchanged.
• Sign-in is pinned to your organisation. An Entra connection accepts only your directory; a Google connection accepts only verified addresses on your Workspace domain.
• An owner can require single sign-on, so a member can't fall back to a SecretWolf password.
• You choose which email domains may provision automatically — someone new from one of those domains gets a member account on their first sign-in. Leave it blank and an invitation is needed first.

What it doesn't do

• OpenID Connect only. There is no SAML option. Both supported providers are full OIDC providers, so SAML would add certificate handling and attack surface for no capability you don't already have.
• No SCIM. Nothing is synced from your directory — no automatic joiners, movers or leavers. Removing someone means removing them in SecretWolf as well as at your provider. If SCIM is a hard requirement, this isn't the product for that part of the job, and we'd rather say so than imply a sync that doesn't exist.
• No group or role mapping. Everyone provisioned this way is a member. Owner is only ever granted inside SecretWolf, never inferred from a directory group.
• One provider per workspace, one connection.
• No single logout. Signing out of SecretWolf doesn't sign you out of Microsoft or Google.
• Members who already had a SecretWolf password keep it unless you require single sign-on. Requiring it is what closes that route.

Owners keep a password route, deliberately

When single sign-on is required, the password form is hidden for members and password sign-in is refused for them. Owners always keep a password route, and that is a design choice rather than an oversight: an expired client secret, a deleted app registration or an outage at your identity provider must never be able to lock a workspace out of its own audit trail. It is the same posture as everywhere else in SecretWolf, where a degraded feature is always preferred to a blocked one.

Setting it up

1. Register SecretWolf as an application in the Entra admin centre or the Google Cloud console, with one redirect URI.
2. Paste the client ID and secret into Single sign-on in your workspace, along with your directory ID (Entra) or Workspace domain (Google), and the email domains that may provision automatically. The secret is stored encrypted and never shown again.
3. Run a test sign-in. A successful round trip verifies the connection, and only a verified connection can be required for members.

There is one redirect URI, and it's the same for every workspace:

https://app.secretwolf.io/signin-oidc

Owner-only, on the Business plan. A step-by-step guide for each provider is built into the page, so nothing here needs a support ticket.

How it fits the rest of the security model

Sign-in is one layer. Underneath it nothing changes: secrets are still AES-256-GCM encrypted, still destroyed on view or expiry, and the audit trail still records metadata only — see security for the detail. Worth noting for a security review: your identity provider is yours, not a new SecretWolf sub-processor, so connecting it doesn't lengthen the list on our compliance page.

Questions people ask