OpenID Connect and user session quotas at an RP

Originally submitted by Andrii Deinega (Andrii Deinega) on 2025-08-20

I’m submitting this issue as a formal proposal to introduce a new extension to OpenID Connect that supports quotas for the number of active sessions at the RP side.

I’d like to see if there is an appetite to do that in the WG + see what the concerns of doing so are.

The core idea behind this proposal is that an RP can specify the desired number of sessions for a user, or in total. The RP includes this information in the authentication request.

For instance, an RP could indicate:

• I would like to have no more than 2 sessions for the same user, or
• I would like to have no more than 10 sessions for all users, or both at the same time like
• I would like to have no more than 5 sessions for the same user and no more than 100 sessions in total.

Note that authentication requests must be protected (JAR), or passed by value, or PAR should be used in this case.

An OP should announce it supports these options in the standard way (through Discovery).

When a user reaches one or two of these quotas, the OP doesn’t complete the auth flow by redirecting a user to the RP. Instead, it informs the user why it can’t complete it at this time. The exact behavior and what OP should return to the user left to be unspecified. Note, the OPs can provide a way for a user to resolve this situation based on their posture, configuration or preferences (say a user may “terminate” his other sessions, etc.).

This allows to meet specific requirements from certain RPs in more or less elegant way (in the way I see it) without a need to implement anything related to managing quotas on their side. In other words, we keep them to be simple by delegating and handling these aspects to OPs completely.

This idea was brought to the table at https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010909.html.

Bitbucket status: open

Bitbucket origin: issue 2184

Start by reading the proposal text and the linked OpenID mailing-list discussion. Clarify whether the working group wants to pursue an extension, then define the request parameters, Discovery metadata, quota behavior, and user-facing flow; the work is done only when the scope and specification requirements are agreed.