Single Sign-On with OIDC: Okta, Entra ID, Google Workspace, and Any OpenID Provider

Your Team's Logins Belong in Your Identity Provider

Your webhook platform holds signing secrets, destination credentials, and the payloads moving through your systems. Until now, everyone on your team reached it with their own password or a Google/GitHub login, managed one account at a time. When someone changed roles or left, you had to remember to remove them from Hookbase as well as from everything else. You also had no way to require that your MFA policy, device checks, and session rules applied to Hookbase too.

Business organizations can now connect Hookbase to their own identity provider over OpenID Connect (OIDC). Team members sign in through Okta, Microsoft Entra ID, Google Workspace, or any other IdP that supports OIDC, and you can choose to make that the only way in.

What's New

• OIDC single sign-on for your organization. Enter an issuer URL, client ID, and client secret, and Hookbase reads the rest from your IdP's discovery document
• Verified domains. You prove that you own a domain with a DNS TXT record, and only email addresses on a verified domain can sign in through your connection
• Require SSO. One switch blocks password login, Google/GitHub login, and password reset for everyone on your verified domains
• "Sign in with SSO" on the login page. When someone types an email on an SSO-enabled domain, the login page offers SSO automatically
• Audit trail. Config changes, domain verifications, and SSO sign-ins are all written to your audit log

Setting It Up

SSO lives under Settings → SSO, and only organization owners can change it.

1. Create an OIDC app in your IdP. Register a web application using the authorization-code flow, and add this redirect URI to it:

https://api.hookbase.app/api/sso/oidc/callback

The SSO settings page shows the same URI, so you can copy it from there.

2. Enter the connection details. Paste your IdP's issuer URL, client ID, and client secret. The default scopes are openid email profile, and you can change them. Hookbase reads <issuer>/.well-known/openid-configuration to find the authorization, token, and JWKS endpoints, so you don't enter those yourself. Any provider that publishes a standard discovery document works.

The client secret is encrypted before it is stored, and the API never sends it back. The form only shows that a secret is set. To change other settings later, leave the secret field blank and the stored secret stays as it is.

3. Add and verify your domain. Add the domain your team's emails use, such as acme.com. Hookbase gives you a TXT record to publish:

Type: TXT Name: _hookbase-sso.acme.com Value: hookbase-sso-verify=<token>

Once the record is live, click Verify. Hookbase looks the record up over DNS-over-HTTPS and marks the domain verified when the value matches.

4. Turn it on. Switch on Enable SSO and save. You can also switch on Require SSO now or later.

Why the Domain Has to Be Verified

Verified-domain binding is the control that keeps SSO safe, so it's worth explaining what it protects against.

An identity provider can put any email address it likes in a token. If Hookbase trusted that claim alone, anyone who controlled a misconfigured or hostile IdP could connect it to their own organization and claim to be ceo@yourcompany.com. To stop that, the callback checks two things after it validates the token. The email's domain must be a verified domain, and that domain must belong to the same SSO connection that started the login. If either check fails, the sign-in is rejected. Domains that are pending or failed verification never resolve to SSO.

Sign-in is also invite-only. Hookbase does not create accounts from an SSO login. The person must already have a Hookbase account and already be a member of your organization. Your IdP decides who can authenticate, and your Hookbase team list decides who gets in. Invite people as you normally do, and from then on they sign in through your IdP.

If the IdP's token says email_verified: false, the login is rejected as well.

What Happens During a Sign-In

The login page calls a small resolve endpoint when someone enters their email. If the email's domain is verified and SSO is enabled for it, a Sign in with SSO button appears. That starts a standard OIDC authorization-code flow:

• PKCE (S256). A fresh code verifier is created for each login, and only its SHA-256 challenge goes to the IdP. A stolen authorization code can't be redeemed without the verifier.
• State, bound to your browser. A random state value is stored server-side for one use and also set in an HttpOnly cookie. The callback rejects the response if the value it gets back doesn't match the cookie. This stops an attacker from completing a login in a victim's browser.
• Nonce. A random nonce goes into the request, and the returned ID token must carry the same value. This blocks replayed tokens.
• Full ID token validation. The ID token's signature is checked against the IdP's published JWKS, and its issuer, audience (your client ID), and expiry are checked too. The discovery document's issuer must match the issuer you configured, and every endpoint in it must use HTTPS.

When all of that passes, Hookbase signs the user in with the same access and refresh tokens a password login would give them. The tokens reach the browser through a single-use code that expires after 120 seconds, not in the redirect URL. After sign-in, the user returns to the page they started from, and only paths within the app are accepted as return addresses.

The resolve, login, callback, and exchange endpoints are all rate-limited per IP.

Requiring SSO

Require SSO is the switch most security teams will care about. When it's on, anyone whose email is on one of your verified domains:

• can't sign in with a password (the API returns 403 with ssoRequired: true, and the login page tells them to use SSO)
• can't sign in with Google or GitHub, so a social login can't get around your IdP's policies
• can't use password reset to get a session

Enforcement happens on the server, on each of those paths. Hiding a form in the browser would not be enough.

Scope and Limits

• OIDC only. Okta, Entra ID, Google Workspace, OneLogin, and other major IdPs all support OpenID Connect, which is what Hookbase supports. SAML is not supported.
• One SSO connection per organization, which can cover several verified domains.
• No just-in-time provisioning. Members must be invited before they can sign in with SSO.
• Business plan. SSO is available on the Business plan, as listed on the pricing page. On other plans the SSO tab shows an upgrade prompt.
• Session-based setup. SSO settings are changed from a signed-in owner session in the dashboard, not with API keys.

Try It

On the Business plan, open Settings → SSO, register Hookbase as an OIDC app in your IdP, add and verify your domain, and switch it on. Try a sign-in from a private window before you turn on Require SSO, and keep an owner session open while you test. Your audit log records each change and each SSO sign-in. For the rest of the security controls Hookbase offers, see Enterprise Security.