Authdog
Log In

Enterprise guide

B2B Authentication

A B2B app has three boundaries, and they are easy to mix up.

Use a project per product, an environment per stage, and an organization per customer company. This guide sets those up in the console, turns on the sign-in that company expects, and checks that a user in two organizations only sees the one they selected. SDK snippets you find elsewhere are illustrations. Do not infer a method your SDK does not document.

Prerequisites

  • An Authdog tenant, project, and an environment that is not production.
  • Console access for authentication, organizations, users, roles, and restrictions.
  • A backend that validates the Authdog session on every protected request.
  • A recovery sign-in for your own operators, so a bad SSO test does not lock you out.
  • The customer's SAML or OIDC settings, once you are ready to federate. You can build the organization before you have them.

One user can belong to several organizations, with a different role in each. Decide that now, because every query in your app has to carry the active organization.

Implementation

  1. Create the environment, and keep its keys to itself. Each environment has its own signing keys, connections, users, and authorization model. Configure development, and test there. A development public key copied into production will validate the wrong sessions. You want a development session to fail in production. Try that once.

  2. Enable only the sign-in methods the product supports. Password, social OAuth, magic link, passkey, TOTP MFA, enterprise SSO. A method you enable and never test is a method an attacker will try. Turn on what you will support this release, and leave the rest off.

  3. Choose where the screens live. The hosted Account Portal gives you sign-in, sign-up, MFA, and account management without a redeploy. Use prebuilt components when the form has to sit inside your layout. Either way, your backend still validates the session. A successful hosted page is not authorization.

  4. Create one organization per customer company. Add the people who belong to it. Remove a membership when they leave that customer. That removal drops access to that organization and leaves the user, and their other memberships, in place. Test with someone in two organizations: remove them from one, and confirm the other still works.

  5. Pick one authorization model and enforce it on the server. RBAC, ABAC, or FGA, one per environment. For RBAC, define permissions and assign roles through the membership. Hiding a button in the client is fine. The route still checks. You are done when an admin in organization A gets a denial on organization B's data.

  6. Add the customer's IdP when they are ready. Open Authentication → Providers, filter to Enterprise, pick the connector, and exchange the values the IdP asks for. Add email domains that do not overlap another connection. Run Test with their test user before you tell the customer to try the portal. The field-by-field version is Authentication and SSO.

  7. Close public sign-up if this is not a public app. Open Lidar → Restrictions and choose public, restricted, or waitlist. Restricted means invitations, manual creation, or SSO. Add domain allowlists or blocklists, and disposable-email controls, when you know which addresses are legitimate. Try an address that should be blocked. The list is not real until that attempt fails.

  8. Give a customer admin a setup link from your backend, not from a chat paste. The Admin Portal can issue a short-lived link scoped to one organization. Generate it only after your server has authorized that administrator. Send it once, over a channel you trust, and do not log the URL.

Security considerations

  • Keep SAML certificates and OIDC client secrets out of the browser. Use HTTPS. Track certificate expiry so rotation is a calendar item, not an outage.
  • Overlapping SSO domains resolve unpredictably. One domain, one connection.
  • Keep the operator recovery path while you change federation or MFA.
  • Treat the organization id on a request as untrusted until it matches a membership you already validated.
  • Review admin changes in Audit logs after you ship a connection or a restriction.

Validation checklist

  • Development and production use different environments and public keys.
  • A user in two organizations sees only data for the active organization.
  • Removing one membership blocks that organization's data without affecting another.
  • SSO test verifies stable subject, email claims, and callback URL.
  • An unrecognized SSO domain does not route to another customer's connection.
  • Restricted sign-up blocks unauthorized self-service registration.

Troubleshooting

SSO discovery picked the wrong connection. Two connections overlap on a parent domain or a subdomain. Remove the overlap and test the address again.

The user is authenticated and sees another customer's data. The bug is in your query, not in the role. Confirm every read is scoped to the organization on the validated session before you edit roles in the console.

The Admin Portal link opens the wrong task. It was minted for a different environment or a different intent. Generate a new one. Do not reuse the old URL.

Next steps