SSO & Authentication
Authentication methods, Single Sign-On configuration, multi-factor authentication, session management, and organization-level security policies. SSO configuration is managed by the Organization Administrator.
Local Authentication
Local accounts are email/password credentials stored and managed by DataKnits directly. Passwords are hashed using bcrypt before storage — plaintext passwords are never persisted.
Local accounts support:
- Admin-initiated password reset without requiring the current password.
- Self-service password change (requires knowledge of the current password).
- Forced password reset on next login (set by an admin when provisioning or after a security event).
- Password reuse prevention — the last 12 passwords cannot be reused.
- Account lockout after configurable consecutive failed login attempts.
JWT & Session Management
DataKnits uses JSON Web Tokens (JWT) for session management. On successful login, the platform issues a signed JWT that the browser includes with every subsequent API request.
| Property | Value / Behaviour |
|---|---|
| Token signing algorithm | HS256 (configurable to RS256 for enterprise deployments) |
| Token lifetime | Configurable by Org Admin. Default: 8 hours. |
| Refresh mechanism | Silent refresh when token is within the last 30 minutes of expiry. |
| Concurrent sessions | Multiple active sessions per user are permitted by default. Org Admin can restrict to one session per user. |
| Session revocation | An admin can revoke all active sessions for a user immediately (e.g., on deactivation or security event). |
| Secret rotation | JWT signing secret is set via JWT_SECRET environment variable. Rotating the secret immediately invalidates all active sessions. |
SSO Overview
DataKnits supports two SSO protocols: SAML 2.0 and OpenID Connect (OIDC) / OAuth 2.0. SSO is configured at the organization level and can be set to optional (users may also use local credentials) or mandatory (all users must authenticate via SSO).
When SSO is enabled:
- Users are redirected to your Identity Provider (IdP) for authentication.
- On successful IdP authentication, the user is returned to DataKnits with a session token.
- User accounts are automatically provisioned on first SSO login if Just-in-Time (JIT) provisioning is enabled.
- Role assignments for JIT-provisioned users are controlled by a default role configured by the Org Admin.
SAML 2.0
SAML 2.0 is suitable for enterprise identity providers such as Microsoft Entra ID (Azure AD), Okta, OneLogin, and PingFederate.
Configuration Fields
| Field | Required | Description |
|---|---|---|
| IdP Entity ID | Yes | The unique identifier of your Identity Provider, provided in the IdP metadata XML. |
| IdP SSO URL | Yes | The URL DataKnits redirects users to for authentication (HTTP-Redirect binding). |
| IdP X.509 Certificate | Yes | The public certificate used by DataKnits to verify the IdP's SAML assertions. Paste the PEM-encoded certificate. |
| SP Entity ID (provided by DataKnits) | — | The unique identifier of DataKnits as the Service Provider. You register this value in your IdP. |
| SP ACS URL (provided by DataKnits) | — | The Assertion Consumer Service URL where the IdP posts SAML responses. Register this in your IdP. |
| Attribute Mapping — Email | Yes | The SAML attribute name that contains the user's email address (e.g., http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress). |
| Attribute Mapping — First Name | Recommended | SAML attribute for the user's first name. |
| Attribute Mapping — Last Name | Recommended | SAML attribute for the user's last name. |
| Sign Authentication Requests | No | When enabled, DataKnits signs outbound SAML AuthnRequests with the SP private key. |
| Force Re-authentication | No | Instructs the IdP to prompt for credentials even if the user already has an active IdP session. |
OIDC / OAuth 2.0
OpenID Connect is suitable for providers such as Google Workspace, Microsoft Entra ID, Okta, Auth0, and Keycloak.
Configuration Fields
| Field | Required | Description |
|---|---|---|
| Client ID | Yes | The application (client) identifier issued by your IdP when you registered DataKnits as an OAuth application. |
| Client Secret | Yes | The client secret issued by your IdP. Stored encrypted (AES-256). |
| Issuer URL / Discovery URL | Yes | The base URL of the IdP. DataKnits appends /.well-known/openid-configuration to auto-discover endpoints. Example: https://accounts.google.com. |
| Redirect URI (provided by DataKnits) | — | The callback URL to register in your IdP application settings. |
| Scopes | Yes | OAuth scopes to request. Minimum: openid email profile. |
| Claims Mapping — Email | Yes | The ID token claim that contains the user's email. Default: email. |
| Claims Mapping — Name | Recommended | ID token claim for the display name. Default: name. |
Multi-Factor Authentication (MFA)
MFA adds a second verification step after password entry. DataKnits supports TOTP-based authenticator apps (e.g., Google Authenticator, Microsoft Authenticator, Authy).
MFA Enforcement Modes
| Mode | Behaviour |
|---|---|
| Disabled | MFA is not available. Users cannot enrol. |
| Optional | Users can enrol MFA voluntarily. MFA is not required to log in. |
| Required | All users must enrol MFA before completing their first login. Logins without MFA are blocked. |
| Required for Admins | MFA is mandatory for any user holding an Admin or Project Owner role. Optional for all other roles. |
MFA enforcement mode is set at the organization level by the Org Admin. When mode is changed from Optional to Required, existing users without MFA enrolled are prompted to enrol on their next login.
When SSO is configured as the authentication method, MFA is typically delegated to the Identity Provider. DataKnits does not enforce its own MFA challenge for SSO users — configure MFA enforcement within your IdP.
Password Policy
Password policy applies to local accounts only. SSO-authenticated users follow their IdP's password policy.
| Setting | Default | Configurable by Org Admin |
|---|---|---|
| Minimum length | 12 characters | Yes (minimum 8) |
| Complexity requirement | Must contain uppercase, lowercase, digit, and special character | Yes |
| Password expiry | Never | Yes — e.g., every 90 days |
| Reuse prevention | Last 12 passwords cannot be reused | Yes |
| Failed login lockout threshold | 5 consecutive failures | Yes (1–10) |
| Lockout duration | 30 minutes (auto-unlocks) | Yes, or admin unlock only |
IP Allowlist
The Organization Administrator can restrict platform access to specific IP address ranges. Login attempts from outside the configured ranges are rejected before authentication is attempted.
- Supports individual IPv4 addresses, IPv4 CIDR ranges, and IPv6 addresses.
- Multiple ranges can be configured (one per line in the UI).
- Allowlist applies to all authentication methods (local and SSO).
- Super Admins are not affected by the IP allowlist — this prevents accidental lockout.
- Changes to the allowlist take effect immediately for new login attempts. Existing sessions are not terminated.