This guide explains how authentication works in Dotwork and how user sessions are created, refreshed, and expired. It is intended for security reviews and advanced troubleshooting.
Audience
Security and compliance reviewers
Identity and IAM administrators
Platform engineers
Site administrators troubleshooting access
When to use this doc
Use this guide if:
Users report unexpected sign-outs
A deactivated user appears to retain access temporarily
You need a high-level understanding of login and session behavior
You are reviewing how Dotwork handles authentication and access changes
Authentication vs Authorization
Dotwork separates:
Authentication — Verifying who the user is.
Authorization — Determining what the user is allowed to do.
A user may successfully authenticate but still be denied access to certain areas if they lack the required permissions.
For detailed permission behavior, see Roles & Permissions.
Session Lifecycle (High Level)
When a user signs in:
A secure session is created.
The session remains active while the user is interacting with the system.
Sessions expire automatically after a period of inactivity.
When a session expires, the user must sign in again.
During normal use, sessions may refresh automatically to maintain continuity.
What Happens When Access Changes
If a user is deactivated
They cannot sign in again.
Existing active sessions may continue until they expire.
Once the session expires, access is fully removed.
If a user’s role or space access changes
Changes apply going forward.
Some updates may not take effect until the user refreshes or re-authenticates.
This behavior is normal for session-based systems.
OAuth and SSO Authentication
For users who sign in via:
Google
Microsoft
GitHub
Enterprise SSO
Authentication is handled by the external identity provider (IdP).
In these cases:
Dotwork does not manage passwords.
Password reset actions in Dotwork do not apply.
Login issues may originate from the identity provider configuration.
System and Service Access
Dotwork also supports non-human access for:
Internal platform services
Connector integrations and automation
These identities:
Operate under system-managed or scoped credentials
Do not inherit end-user roles (Administrator, Contributor, Viewer)
Cannot log in interactively
For customer-configured connectors and integrations, access is limited to the credentials and permissions granted within that configuration.
Operational Notes
Sessions expire automatically after inactivity.
Deactivation prevents future login attempts.
Active sessions may persist briefly after access changes.
Owner permissions are system-controlled and cannot be modified in the UI.
If you’re troubleshooting an access issue and it is not related to login behavior, see: