Authdog
Log In

Workflows guide

No-code Identity Flows

Most of the hosted sign-in can change in the console, without a deploy.

Work in a development environment, turn on only the methods you will support, and do not call it done until a protected backend route accepts a good session and rejects a bad one. The Flows module is a read-only preview. There is no production editor, no publishing API, and no rollback. If you need a change, you change the underlying settings, not a flow canvas.

Prerequisites

  • An Authdog project and a development environment you can break.
  • Console access for authentication, branding, domains, users, and Lidar.
  • The hosted Account Portal, or a supported prebuilt component, already pointed at that environment.
  • A test user for each sign-in path, and a backend route that validates the session.
  • Access to the customer's IdP if this journey includes enterprise SSO.

Use the hosted Account Portal when you want the least application code. Use components when the screen has to render inside your layout. Build a headless flow only against the APIs your SDK version actually documents.

Implementation

  1. Confirm the environment before you click anything. Check the tenant, project, and environment in the console chrome. Leave production alone until the whole journey has passed in development. A branding tweak in the wrong environment is how you retheme a customer logo on a Tuesday.

  2. Turn on the methods you will actually test. Password, social, magic link, passkeys, TOTP MFA, enterprise SSO. Provider credentials live in Authdog and at the upstream provider. They do not live in frontend code. After you save, sign in with each method you enabled, and confirm a method you disabled is gone.

  3. Add enterprise routing only when a customer needs it. Create each SAML or OIDC connection under Authentication → Providers. Give it email domains no other connection uses. Run Test before you try the same user in the portal. A green test and a failed portal sign-in usually means the discovery domain does not match the address you typed.

  4. Decide who is allowed to start. Open Lidar → Restrictions. Public is self-service. Restricted is invitations, manual creation, or SSO only. Waitlist holds everyone else. Domain allowlists, blocklists, and disposable-email controls apply to sign-up. Try one address that should enter and one that should not. The mode is real when the second attempt fails.

  5. Add TOTP, and keep another way in. Enable MFA, enroll a development user, and complete the TOTP challenge. What ships today is TOTP. Not SMS, not push, not a security key. Keep a recovery path that does not depend on that device while you test. If the only operator account is the one you just enrolled, you are one lost phone away from a lockout.

  6. Theme the environment, then check the callback host. Set logo, colors, copy, and localization. If you use a custom identity domain, open the provider and compare its callback allowlist to the URL Authdog is displaying now. A domain change moves that URL. The IdP will not follow you.

  7. Read the flow previews, and do not try to edit them. Standard login, User offboarding, and User impersonation under Flows describe what the product intends. They are read-only. A preview is not a saved branch you can publish. Change authentication, restrictions, and branding instead, then look at the preview again to see whether it matches.

  8. Copy verified settings forward, and re-test in each stage. Reproduce what you tested from development into staging, then production. Callbacks, MFA, and restrictions are per environment. A setting that worked in development is a rumor until you repeat the sign-in in the next stage.

For a customer company, pair this with organizations, invitations, and SSO from B2B authentication. The hosted page gets them in. The organization decides what they can see.

Security considerations

  • One setting can lock every user in the environment out. Keep an operator recovery path, and change one control at a time.
  • OIDC secrets, SAML certificates, TOTP seeds, and Admin Portal links are secrets. Treat them that way.
  • A hosted success screen is not a session your API should trust. Validate on the backend route.
  • Use Audit logs to see what was recorded, and confirm the event type exists before you alert on it.

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

You cannot edit a flow. That is the product. Flows is a preview. Change the authentication, restriction, or branding setting the preview is describing.

A provider does not show up at sign-in. It is inactive, or you are in a different environment than the one where you created it. For SSO, an overlapping discovery domain will also send the user somewhere else. Remove the overlap.

MFA sends the user back to sign-in. They do not have an active TOTP enrollment in this environment. Enroll them here, or turn MFA off for the test until you do.

Next steps