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.
- A test user for each sign-in path and a backend route that validates the session.
- Customer IdP access if the flow includes enterprise SSO.
Use the hosted Account Portal for the least application code, components when the experience must render inside your layout, and headless custom flows only with documented APIs for your exact SDK version.
Implementation
Start in a development environment. Confirm the selected tenant, project, and environment. Keep production untouched until the full journey passes validation.
Select supported authentication methods. Password, social, magic-link, passkeys, TOTP MFA, or enterprise SSO. Provider credentials belong in Authdog and the upstream provider, never in frontend code.
Configure enterprise routing if required. Create each SAML/OIDC connection under Authentication → Providers, add unique discovery email domains, and use Test before a portal sign-in check.
Control who can enter the flow. In Lidar → Restrictions, choose Public (self-service), Restricted (invitations, manual creation, or SSO only), or Waitlist. Optional domain allowlists/blocklists and disposable-email controls apply to sign-up.
Add MFA carefully. Enable MFA, enroll a development user, and verify the TOTP challenge. Current documentation supports only TOTP, not SMS, push, or security keys. Keep another verified recovery path while testing.
Apply the environment theme. Configure logo, colors, copy, and localization. If using a custom identity domain, confirm the provider callback allowlist matches the URL Authdog currently displays.
Inspect the flow previews. Standard login, User offboarding, and User impersonation in Flows describe intended behavior but are read-only, not evidence of a persisted editable branch.
Promote only verified configuration. Reproduce tested settings from development toward staging and production; re-run provider callbacks, MFA, and restrictions in each stage.
For B2B onboarding, combine this 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 and change one control at a time.
- Treat OIDC secrets, SAML certificates, TOTP seeds, and Admin Portal links as sensitive.
- Always validate the completed session on protected backend routes, a hosted success screen is not authorization.
- Use Audit logs to verify recorded activity, but confirm the expected event exists first.
Validation checklist
- Enabled sign-in methods appear; disabled methods do not.
- Each configured path (password, social, magic-link, passkey, SSO, MFA) completes successfully.
- Public, restricted, or waitlist behavior matches the selected mode.
- Redirect and provider callback URLs use the intended host and HTTPS.
- Backend accepts a valid session and rejects missing, expired, 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, that's expected: Flows panels are read-only previews. If a provider does not appear, confirm it's active in the selected environment; for SSO routing errors, remove overlapping discovery domains. If MFA loops back to sign-in, confirm the user has an active TOTP enrollment in the same environment.
Next steps
- Design customer tenancy with B2B authentication.
- Establish event review with Audit logs.
- Add preventive and response controls with Threat mitigation.
- Send selected observed events downstream with SIEM security events.