Authdog
Workflows guide

No-code Identity Flows

Authdog can change much of the hosted identity experience through environment configuration rather than application code: sign-in methods, enterprise connections, MFA, restrictions, branding, localization, domains, and notification channels are console-managed. The current console Flows module shows read-only previews for standard login, user offboarding, and impersonation; repository service code does not verify a production drag-and-drop flow editor, publishing API, version history, or rollback mechanism. This guide therefore documents the practical configuration workflow available now.

Prerequisites

  • An Authdog project with an isolated development environment.
  • Console access for authentication, branding, domains, users, and Lidar settings.
  • A hosted Account Portal integration, or a supported prebuilt component already connected to the same environment.
  • A test user for each sign-in path and a backend route that validates the resulting session.
  • Customer IdP access if the flow includes enterprise SSO.

Use the hosted Account Portal when you want the least application code. It supplies sign-in, sign-up, MFA, and account-management screens. Environment configuration is reflected by hosted screens without redeploying your application. Components provide a middle ground when the experience must render inside your layout. Headless custom flows create more implementation responsibility and should use only documented APIs for the exact SDK version.

Implementation

  1. Start in a development environment. Confirm the selected tenant, project, and environment before making changes. Environments isolate keys, connections, users, authorization configuration, and themes. Keep the production environment untouched until the full journey passes validation.

  2. Select supported authentication methods. Configure password, social providers, magic-link sign-in, passkeys, TOTP MFA, or enterprise SSO according to your requirements. Only enabled methods should appear in the environment's sign-in experience. Provider credentials belong in Authdog and the upstream provider, never in frontend code.

  3. Configure enterprise routing if required. Under Authentication → Providers, create each enterprise SAML or OIDC connection, enter its exact IdP values, and add discovery email domains. Use unique, non-overlapping domains. Run the connection's Test action and then test through the hosted portal with a matching address.

  4. Control who can enter the flow. Open Lidar → Restrictions and choose a sign-up mode:

    • Public allows self-service sign-up.
    • Restricted disables general sign-up while allowing invitations, manual creation, or enterprise SSO.
    • Waitlist disables normal sign-up but allows people to join a waitlist.

    Optional restrictions include email-domain allowlists and blocklists, applying those lists to sign-in, blocking disposable-email sign-ups, and limiting distinct subaddresses for one base email. Add at least one domain before saving an enabled allowlist.

  5. Add MFA carefully. Enable multi-factor authentication for the environment, enroll a development user, and verify the six-digit TOTP challenge. Enrollment is not complete until the initial code verifies. Current repository documentation does not support SMS, push, or security keys as MFA factors. Keep another verified sign-in or recovery path while testing.

  6. Apply the environment theme. Configure logo, colors, copy, and localization for the environment. Hosted screens and supported components consume environment configuration. If you use a custom identity domain, confirm that any provider callback allowlist contains the URL currently displayed by Authdog.

  7. Inspect the flow previews. Open Flows and review Standard login, User offboarding, and User impersonation. These views describe intended ordered behavior but are explicitly marked Read only. Do not use the preview as evidence that an editable branch, approval, or automation was persisted.

  8. Promote only verified configuration. Reproduce or promote the tested configuration from development toward staging and production according to your deployment process. Signing keys remain distinct per environment. Re-run provider callbacks, MFA, restrictions, and session validation in each stage.

For B2B onboarding, combine this workflow with organizations, invitations, and SSO from B2B authentication.

Security considerations

Configuration changes can lock out every user in an environment. Preserve an operator recovery path, test restrictions with both allowed and denied accounts, and change one control at a time. Treat OIDC secrets, SAML certificates, TOTP seeds, backup codes, and temporary Admin Portal links as sensitive.

Always validate the completed Authdog session on protected backend routes. Seeing a hosted success screen, returning to the application, or passing MFA is not authorization by itself. Enforce permissions and organization boundaries server-side.

Avoid claims that the current read-only flow preview provides versioning, rollback, approval gates, conditional risk routing, or publish history. Use Audit logs to verify recorded identity and administrative activity, but confirm the expected event exists before making it part of a control.

Validation checklist

  • Enabled sign-in methods appear; disabled methods do not.
  • Password, social, magic-link, passkey, SSO, and MFA paths used by your application each complete successfully.
  • Failed and cancelled authentication return a safe, understandable result.
  • Public, restricted, or waitlist behavior matches the selected mode.
  • Allowlisted and blocklisted addresses produce expected results for sign-up and sign-in.
  • Hosted branding, copy, and localization match the selected environment.
  • Redirect and provider callback URLs use the intended host and HTTPS.
  • Backend accepts a valid environment session and rejects missing, expired, revoked, or wrong-environment sessions.
  • Relevant activity appears in Audit with the expected environment, user, and event type.

Troubleshooting

If a console flow cannot be edited, this is expected: current Flows panels are read-only previews. Make supported changes in authentication, restrictions, branding, domains, users, or notification settings.

If a provider does not appear, confirm it is active in the selected environment. For SSO routing errors, remove overlapping discovery domains and verify the email domain exactly. For callback failures after a custom-domain change, update the provider allowlist to the callback URL now shown in Authdog.

If MFA loops back to sign-in, confirm the user has an active TOTP enrollment and that pending state belongs to the same environment. Do not call hosted MFA routes directly; they depend on Authdog-managed cookies.

Next steps