Authdog
Enterprise guide

B2B Authentication

Authdog supports B2B authentication by combining environment-scoped sign-in configuration with application-level organizations. An environment supplies isolated keys, connections, users, and authorization configuration; organizations inside that environment represent customer companies, memberships, invitations, and organization-scoped roles. This guide uses console workflows because SDK surfaces vary and must not be inferred from illustrative examples.

Prerequisites

  • An Authdog tenant, project, and non-production environment.
  • Console access to configure authentication, organizations, users, roles, and restrictions.
  • A backend that validates the Authdog session on every protected request.
  • At least one recovery sign-in method for operators while enterprise SSO is being tested.
  • For enterprise federation, access to the customer's SAML 2.0 or OIDC identity-provider settings.

Decide the boundary before configuring anything. Use separate projects for separate products and separate environments for development, staging, and production. Model customer companies as organizations within one environment. A user can belong to multiple organizations, and each membership can carry different organization-scoped roles.

Implementation

  1. Create the environment structure. Select the project and development environment in the console. Each environment has its own signing keys, public key, connections, user store, and authorization model. Configure and test in development before reproducing the intended settings in production; never reuse a development public key in a production build.

  2. Choose sign-in methods. Under the environment's authentication settings, enable only methods your application will support. Authdog product documentation verifies password, social OAuth, magic-link, passkey, TOTP MFA, and enterprise SSO capabilities. Availability differs by method and flow, so test the exact hosted experience you plan to expose.

  3. Choose the user experience. The hosted Account Portal supplies sign-in, sign-up, MFA, and account-management screens and reflects environment configuration without an application redeploy. Prebuilt components are another option when authentication must appear inside your layout. Prefer these supported surfaces over a headless flow unless you have verified the exact SDK primitives for your chosen package.

  4. Create organizations and memberships. Create one organization per customer company. Add existing users through memberships or invite new users by email. Removing a membership should remove access to that organization without deleting the user's account or other memberships. Assign organization roles through memberships, allowing the same user to be an administrator in one customer and a member in another.

  5. Define server-enforced authorization. In the environment, choose one authorization model: RBAC, ABAC, or FGA. For RBAC, define granular permissions such as invoices:read, group them into roles, and assign those roles through organization memberships. On each backend request, validate the session, select data using the active organization context, and enforce the required permission. Client-side role checks improve UX but are not an authorization boundary.

  6. Configure enterprise SSO. Open Authentication → Providers, filter to Enterprise, then choose a vendor-specific or generic SAML/OIDC connector. Copy the displayed Authdog service-provider or callback values into the IdP and enter the IdP configuration in Authdog. Add non-overlapping email domains for discovery. SAML configuration can use metadata XML or a metadata URL; OIDC requires the displayed callback URL, discovery URL, client ID, and client secret. Use the connection's Test action before rollout.

  7. Restrict onboarding where appropriate. In Lidar → Restrictions, choose public, restricted, or waitlist sign-up. Restricted mode allows access through invitation, manual creation, or enterprise SSO. Domain allowlists and blocklists can apply to sign-up and, when selected, sign-in. Disposable-email and subaddress controls are also available for sign-up.

  8. Add customer-managed setup when needed. Authdog's Admin Portal can issue a short-lived, organization-scoped setup link for SSO, directory sync, or domain verification. Generate it only from trusted backend code after authorizing the customer administrator. Treat the link as a bearer credential and verify the resulting configuration separately.

Security considerations

Keep SAML certificates and OIDC client secrets out of browser code. Use HTTPS for discovery, SSO, logout, and callback URLs, and track SAML certificate expiry. Avoid overlapping SSO discovery domains because resolution can become unpredictable.

Maintain a recovery route while changing federation or MFA policy. TOTP is the currently documented MFA factor; do not describe it as phishing-resistant. For stronger passwordless sign-in, test passkeys in the hosted identity flow and preserve another verified recovery method.

Treat organization selection as untrusted input until matched against a validated membership. Every query for customer data must include the active organization boundary, and every privileged operation must be checked server-side.

Review administrative and authentication activity using the workflow in Audit logs. Forward selected events only after validating their observed payloads as described in SIEM security events.

Validation checklist

  • Development and production use different Authdog environments and public keys.
  • Hosted sign-in completes for each enabled method and returns to an allowed application URL.
  • A user in two organizations sees only data for the active organization.
  • Removing one membership blocks that organization's data without affecting another membership.
  • Organization roles permit and deny backend actions as designed.
  • SSO test verifies stable subject and email claims, IdP MFA or conditional access, and callback URL.
  • An unrecognized SSO domain does not route to another customer's connection.
  • Restricted sign-up blocks an unauthorized self-service registration.
  • Audit activity identifies the environment, user, event type, and relevant organization context.

Troubleshooting

If SSO discovery selects the wrong connection, inspect active connections and remove overlapping parent or subdomains. If OIDC setup fails, use the exact discovery document and callback URL shown by Authdog rather than a guessed issuer or redirect URL. For SAML failures, verify the SSO URL, signing certificate, entity ID or audience, and ACS URL on both sides.

If users authenticate but see the wrong customer data, debug backend organization scoping before changing Authdog roles. Confirm the session is valid for the intended environment, the user has an active membership, and every data query uses the selected organization.

If the Admin Portal link expires or opens the wrong task, generate a new link for the correct environment, organization, and intent. Link creation alone does not prove setup succeeded.

Next steps