Skip to main content

Security Settings

This guide covers Settings → Security - workspace-wide policy that applies to all members and is managed by admins.

For your personal sign-in settings (changing your password, enrolling 2FA, viewing your trusted devices, connecting Google/Microsoft accounts to your login), see My account → Security.

If you're an organization admin you'll see the full Security page. Non-admins see the same page but everything is read-only.

The Security page layout​

The Security page has a left rail with four sub-sections - all admin-only:

Sub-sectionWhat it controls
AuthenticationPassword policy + 2FA enforcement
SessionsInactivity timeout + account lockout + "remember me"
Single sign-onIdentity provider setup + SSO enforcement
Network accessIP allowlist

The active sub-section is reflected in the URL (?section=sso, …) so you can bookmark or share a deep link.

Authentication​

Organization-level password and 2FA policy.

Password policy​

  • Minimum password length - admins set the floor. 12 characters is recommended; 8 is the absolute minimum.
  • Prevent reuse of last N passwords - block the same password from being chosen twice within a window.
  • Require mixed characters - when on, every new password must contain at least one uppercase letter, one lowercase letter, and one number. Off by default. Length-only policies are generally stronger than complexity-only policies; only turn this on if you have a specific compliance requirement.
  • Expire passwords periodically - when on, members are forced to rotate passwords every N days. Off by default for the same reason - forced rotation often results in weaker, more predictable passwords. Enable only for compliance.

Two-factor authentication​

  • Require 2FA - when on, every member must enroll a TOTP authenticator before they can access the workspace.
tip

The Authentication panel is org-policy only. To set up your own 2FA, see My account below.

Sessions​

Inactivity timeout​

When on, members are automatically signed out after N minutes of inactivity. Trusted devices still see a quiet re-auth prompt rather than a full sign-in.

note

The session timeout setting is recorded today but not yet enforced in the auth layer. Tracked as a follow-up.

Account lockout​

After N failed login attempts in a row, the account is locked for the configured duration. Members can unlock via an emailed link or an admin override.

Allow "remember me" for 30 days​

When on, members will (in a future release) see a "Stay signed in" checkbox on the login page that extends their session to 30 days.

note

The admin policy can be toggled today and is stored on the server, but the login-page checkbox itself is part of a follow-up release. Leaving this off has no user-visible effect right now.

Single sign-on (SSO)​

Let members sign in with your organization's identity provider. You can configure any of Google Workspace, Microsoft Entra, or Okta. Once at least one provider is enabled, you can optionally enforce SSO-only sign-in for the whole workspace.

Identity providers​

Each provider is shown as a card with its status:

  • Not configured - click Configure to enter credentials.
  • Active (green pill) - the provider is configured and members see its sign-in button on the login page.
  • Disabled (gray pill) - credentials are saved but the provider is off. Members do not see it on the login page.
  • Auto-create (blue pill, if turned on inside the provider's config) - first-time SSO users are auto-provisioned with the role you picked.

Toggle the switch on a provider card to enable / disable it. Click Edit to update credentials.

Configuring a provider​

Click Configure (new) or Edit (existing) on any provider card to open the configuration modal. Every modal contains:

  1. Setup guide - a collapsible checklist of the steps to perform inside the IdP (Google Cloud Console / Azure Portal / Okta Admin). The steps are tailored per provider.
  2. Redirect URI - the value you need to paste into your IdP's "Authorized redirect URIs" field. The Copy button puts it on your clipboard.
  3. Client ID + Client Secret - copied from your IdP. The secret is stored encrypted; if you're editing, leave it blank to keep the existing value.
  4. Provider-specific field:
    • Microsoft: Tenant ID - use common for multi-tenant or a specific tenant UUID.
    • Okta: Okta domain - your *.okta.com hostname.
  5. Allowed email domains (comma-separated) - restrict SSO sign-in to specific email domains. Leave empty to allow any domain.
  6. Auto-create members on first sign-in - toggle. When on, pick the Default role for new accounts.

Save & test connection​

The modal has one primary action. The first save reads Save & test connection; when editing or resuming, it reads Test & save changes.

Clicking it:

  1. Saves the credentials with the provider disabled (so a broken provider never goes live on the login page).
  2. Calls your IdP to verify the credentials work.
  3. On success, flips the provider to enabled and closes the modal - the card shows the Active pill.
  4. On failure, leaves the provider disabled and shows the IdP's error message in an amber band right above the action button. Fix the wrong field and click again. The error clears as soon as you start typing.

If you close the modal after a failed Save & test, the provider stays in a half-finished "saved but disabled" state. Reopening it shows Resume {provider} sign-on setup with your fields pre-filled, plus a Discard setup button next to Cancel - finish or trash it from there.

IdP setup walkthroughs​

Google Workspace​

  1. Go to Google Cloud Console
  2. Create a new project or select an existing one.
  3. Navigate to APIs & Services → Credentials.
  4. Click Create Credentials → OAuth 2.0 Client IDs.
  5. Configure the OAuth consent screen if prompted.
  6. Set the application type to Web application.
  7. Add the redirect URI shown in the modal to Authorized redirect URIs.
  8. Copy the Client ID and Client Secret into Joryio.

Microsoft Entra​

  1. Go to Azure Portal
  2. Navigate to Microsoft Entra ID → App registrations → New registration.
  3. Choose supported account types:
    • Common - all Microsoft accounts (work + personal)
    • Organizations - work / school accounts only
    • Consumers - personal accounts only
  4. Add the redirect URI shown in the modal under the Web platform.
  5. In Certificates & secrets, create a new client secret.
  6. Copy the Application (client) ID, the client secret, and the Directory (tenant) ID into Joryio.

Okta​

  1. Open the Okta Admin Console.
  2. Applications → Create App Integration.
  3. Choose OIDC – OpenID Connect, then Web Application.
  4. Add the redirect URI shown in the modal to Sign-in redirect URIs.
  5. Under Assignments, configure who can use the app.
  6. Copy the Client ID, Client secret, and your Okta domain (e.g. your-company.okta.com) into Joryio.

SSO enforcement​

The bottom card in the SSO sub-section. When enforcement is on, password sign-in is disabled across the entire workspace - members must use their identity provider. The toggle is disabled until at least one provider is enabled, with an amber warning explaining why.

Admins keep a one-time recovery code in case the IdP becomes unreachable.

Network access​

A single IP allowlist card. When enabled, only sign-ins originating from one of the listed IPv4 addresses or CIDR ranges are accepted. Members signing in from outside the allowlist get a permission error.

Leave empty (or toggle the card off) to allow sign-in from anywhere.

Personal sign-in settings​

Personal sign-in controls (your own 2FA, trusted devices, password change, connected Google/Microsoft/Okta accounts, "sign out everywhere") live under My account on a separate page.

See My account → Security.

Best practices​

  1. Require 2FA for everyone - turn it on in Authentication once your team is enrolled.
  2. Restrict allowed email domains on every SSO provider. Stops random Google accounts from signing into your workspace.
  3. Configure at least one SSO provider before enforcing SSO - the toggle is disabled until you do, but the warning is there for a reason.
  4. Use the IP allowlist if you have a clear office / VPN range. Skip it for fully remote teams - false-positive lockouts are painful.