Skip to content
Calcrivo

OIDC Session Calculator

Size an OpenID Connect deployment: ID token renewals, session-check polling load, session store memory and per-node request rate.

Inputs

users
minutes
minutes
seconds
bytes
nodes
apps

Requests per IdP Node

2,501.16req/s

ID Token Renewals per Session

7

Authorisation Requests per Day

400,000

Session-Check Polling Rate

10,000.0req/s

Session Store Memory

42.92 MiB

Back-Channel Logout Calls per Sign-Out

6

Assessment

Session-check polling dominates IdP load — lengthen the interval or move to back-channel logout

Step by step

  1. Values used

    Concurrent signed-in users = 50,000 users; Single sign-on session length = 480 minutes; ID token lifetime = 60 minutes; check_session_iframe poll interval = 5 seconds; Session state stored per user = 900 bytes; Identity provider nodes = 4 nodes; Relying parties per session = 6 apps

  2. OIDC Session

    renewals per session = ceil(session length ÷ ID token lifetime) − 1; polling load = concurrent sessions ÷ poll interval.

  3. Per-node load

    requests per node = (polling rate + authorisation rate) ÷ IdP nodes.

  4. Requests per IdP Node

    = 2,501.16 req/s

  5. ID Token Renewals per Session

    = 7

  6. Authorisation Requests per Day

    = 400,000

  7. Session-Check Polling Rate

    = 10,000.0 req/s

  8. Session Store Memory

    = 45,000,000.00

  9. Back-Channel Logout Calls per Sign-Out

    = 6

How it works

OIDC session load has two very different components. Authorisation and silent renewal traffic scales with session length divided by token lifetime, but session-status polling scales with concurrency divided by the poll interval — and at a few seconds per poll it dwarfs everything else. Most OIDC capacity surprises are polling, not logins: fifty thousand sessions polling every five seconds is ten thousand requests per second before a single user actually signs in.

Formulas

OIDC Session

renewals per session = ceil(session length ÷ ID token lifetime) − 1; polling load = concurrent sessions ÷ poll interval.

check_session_iframe
Hidden iframe each relying party polls to detect IdP sign-out
poll interval
Seconds between session-state checks, commonly 3–5

Per-node load

requests per node = (polling rate + authorisation rate) ÷ IdP nodes.

authorisation rate
Initial sign-ins plus silent renewals, spread across the day

Frequently Asked Questions

How is OIDC Session calculated?

renewals per session = ceil(session length ÷ ID token lifetime) − 1; polling load = concurrent sessions ÷ poll interval. OIDC session load has two very different components. Authorisation and silent renewal traffic scales with session length divided by token lifetime, but session-status polling scales with concurrency divided by the poll interval — and at a few seconds per poll it dwarfs everything else.

Why does OIDC Session matter?

Most OIDC capacity surprises are polling, not logins: fifty thousand sessions polling every five seconds is ten thousand requests per second before a single user actually signs in.

What values do I need to enter?

This calculator takes 7 inputs: Concurrent signed-in users, Single sign-on session length, ID token lifetime, check_session_iframe poll interval, Session state stored per user, Identity provider nodes, Relying parties per session. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Should I use check_session_iframe or back-channel logout?

Back-channel logout where you can. Session polling was designed before third-party cookie restrictions and now both leaks capacity and breaks in modern browsers. Back-channel logout pushes one signed request per relying party at sign-out, which is bounded work rather than continuous load.

How long should an SSO session last?

Long enough to avoid re-prompting through a working day — eight hours is a common default, with Entra ID defaulting to a rolling window — and short enough that an unattended device does not stay signed in indefinitely. Pair a long session with short ID and access tokens so revocation still lands quickly.

You might also need