Login Sharing Restriction

Overview

Login Sharing Restriction lets you control how many active sessions a user can have at the same time. When a user exceeds your defined session limit, you can automatically end their older sessions, show them a warning, or require re-verification — all configured directly in the workflow editor.

This is useful for:

Subscription enforcement — prevent credential sharing across multiple users.
Security hardening — reduce exposure from forgotten or compromised sessions.
Compliance — enforce single-device login policies for sensitive applications.

How It Works

Two workflow nodes work together:

Node	What It Does
Data Query	Checks the user's Active Session Count and routes the flow based on whether the limit is exceeded.
Force Logout	Ends all pre-existing sessions for the user, keeping the current login active.
Logout	Ends the current session (the new login attempt), effectively blocking it. Use this to hard-deny new logins when the limit is already reached.

When a user logs in and the session count meets or exceeds your threshold, the workflow takes the restricted path. In flows that use Force Logout, the current login succeeds and only pre-existing sessions are revoked. In flows that use Logout, the current login attempt is denied.

Choose a Restriction Pattern

Pick the experience that fits your use case:

Warn the user (Recommended)

Show a screen informing the user that their other sessions will be ended. They acknowledge and continue.

Best for: Consumer apps where transparency builds trust.

Silent revocation

Older sessions are revoked automatically without any interruption to the current login.

Best for: Subscription or enterprise apps where silent enforcement is preferred.

Require re-verification

The user must verify their identity (e.g. via OTP) before older sessions are revoked.

Best for: High-security applications where explicit confirmation is required before any session action.

When the session limit is already reached, deny the new login attempt entirely. The Logout node invalidates the current session before an access token is issued, so the user is turned away rather than displacing an existing session.

Best for: Strict subscription or compliance scenarios where concurrent session count must be hard-capped and no automatic eviction is acceptable.

Setup

Prerequisites

An active Identity Orchestration workflow with at least one authentication node (standard login, social login, etc.)

Step 1 — Add a Data Query Node

Go to Admin Console > Orchestration > Workflows and open your workflow.
After your authentication node, add a Data Query node.
Configure the rule:
- Field: Active Session Count
- Operator: >=
- Value: your session limit (e.g. 3)
Save the node.

Step 2 — Connect the Restriction Path (`true` output)

Wire the true output to your chosen pattern:

Warn: true → Session Limit Page → Force Logout
Silent: true → Force Logout
Re-verify: true → OTP Verification → Force Logout
Block new login: true → Logout (ends the current login; no access token is issued)

Step 3 — Connect the Normal Path (`false` output)

Wire the false output directly to your Access Token Config node. This is the path taken when no limit is exceeded.

Step 4 — Complete the Flow

Connect Force Logout → Access Token Config → Success.

Step 5 — Test

Log in with the same account across more than N devices or browsers. The next login after the limit is reached should route through the true path, and only the newest session should remain active.

Changing the Session Limit

Open the Data Query node in the workflow editor and update the threshold value (e.g. change >= 3 to >= 5). Changes take effect immediately for new login attempts — no redeployment needed.

Key Behaviors

Behavior	Detail
Current session is always kept	Force Logout never revokes the session that triggered it.
Linked accounts	Sessions across all linked profiles are counted and revoked together.
Lookup failures are non-blocking	If the session count cannot be retrieved, the user is not blocked.
Interim tokens excluded	Forgot-password and PIN session tokens do not count toward the limit.
Per-workflow configuration	Each workflow can have its own session limit independently.