Authentication

ZopDay supports four sign-in methods. Pick whichever fits your org’s identity story; they all converge on the same workspace and the same RBAC model after sign-in.

Sign-in methods

Which methods appear on your sign-in page depends on what your organisation has enabled. Whichever method you use, the workspace experience after sign-in is identical.

SAML / SSO

SAML is the path for orgs that need IdP-driven access control (Okta, Azure AD, Auth0, OneLogin, and other SAML 2.0-compliant IdPs).

How a sign-in flows

1. User enters email

   User types their work email on the sign-in page. ZopDay looks up the email domain against active SAML configurations.

2. Redirect to IdP

   Match found → ZopDay redirects to the IdP’s SAML login URL.

3. IdP authenticates

   IdP runs its own MFA / device check / whatever. On success, posts a signed SAML assertion to ZopDay’s ACS callback.

4. ZopDay validates and creates session

   The auth service validates the SAML signature, reads the user attributes, creates or updates the ZopDay user, and starts the session. The user lands in the workspace.

If no SAML config matches the email domain, sign-in falls back to whichever OAuth or password methods are enabled.

SAML configuration is managed by ZopDay support during onboarding; contact your account team with your IdP metadata to enable SAML on a domain.

Authorization (after sign-in)

Authentication only proves who you are. Authorization decides what you can do. After sign-in, every gateway request is checked against the RBAC policy table.

• System roles: Admin, Editor, Viewer.
• Custom roles: per-policy resource scoping, anchored to any scope.
• Team-scoped access: team members inherit their role’s policies scoped to the team’s assigned resource UIDs.

See the architecture canvas + Settings → Roles in the app for the full policy list and current assignments.

Personal Access Tokens

For automation, CI, and CLI use, generate a Personal Access Token (PAT) from your profile menu.

• PATs carry the issuing user’s policies; they cannot grant more access than the user already has
• Revocable at any time from the profile menu
• The audit log captures the issuing PAT against every PAT-driven action so events stay traceable to the originating user

Session expiry

Sessions expire after the configured idle window. When a session expires:

• The frontend detects the 401 on the next gateway call
• A modal re-prompts for sign-in without losing your in-progress UI state (form fields, drawers, navigation)
• After successful re-auth, the in-flight request is retried automatically

This avoids the “I lost an hour of typing into a form” failure mode.

Sign-in troubleshooting

Symptom	Likely cause
SAML redirect loop	Email domain not in any active SAML config, or config marked inactive
”Invalid SAML response” after IdP login	IdP signing certificate rotated since the config was created; needs re-issue
OAuth method missing on sign-in page	The OAuth provider is not enabled for your organisation
403 after sign-in	RBAC denial; user has no policy granting access to the targeted resource. Ask an admin to grant the missing policy via Settings → Roles.