Skip to main content
Identity Authority
Category: Tokens & Sessions

Session Broker

Also known as: Connection Broker, RD Connection Broker, TS Broker
Simply put

A session broker is a control point that sits between users and the systems they want to reach, directing each user's connection to the correct destination such as a remote desktop, virtual desktop, or published application. It keeps track of active connections so that a returning user can be reconnected to their existing session rather than starting a new one.

Formal definition

A session broker is a control-layer component placed between requesting users and a pool of target systems (commonly remote desktop or virtual desktop session hosts) that routes each connection to an appropriate session host, desktop, or published application. In typical deployments it maintains a database or state store of brokered connections, enabling session affinity and reconnection to an existing session rather than instantiating a new one. The exact division of responsibility varies by product and configuration: for example, Microsoft's Remote Desktop Connection Broker manages incoming connections to RD Session Host farms and directs reconnecting clients to their prior sessions. Whether the broker performs user authentication itself, or delegates it to a separate identity provider or session host, depends on the specific implementation and deployment; brokering (connection routing and session state management) is a distinct concern from authentication and should not be assumed to include it.

Why it matters

In session-based access architectures such as remote desktop and virtual desktop deployments, the broker is the component that determines where a user's connection lands and whether that user is reconnected to an existing session or given a new one. This makes it an operationally critical control point: if the broker or its connection state store is unavailable, users may be unable to reach their published applications and desktops, and reconnection to in-progress sessions can break. Understanding the broker's role helps architects reason clearly about availability, session affinity, and the user experience of returning to an interrupted session.

Just as important is understanding what the broker is not. Brokering, the routing of a connection to an appropriate target and the management of session state, is a distinct concern from authentication (verifying who the user is) and authorization (determining what the user may access). Whether a broker performs authentication itself or delegates it to a separate identity provider or to the session host depends entirely on the specific product and deployment. Treating connection routing as if it inherently includes identity verification can lead to gaps in how access is actually enforced.

Because the exact division of responsibility varies by vendor and configuration, IAM and infrastructure teams should confirm, per deployment, which component authenticates users, which authorizes access to which resources, and where session state is stored. Documenting these boundaries explicitly avoids the common error of assuming the broker is a single, all-encompassing access gate when in most deployments it is one part of a larger chain.

Who it's relevant to

System Administrators
Administrators managing remote desktop or virtual desktop environments rely on the broker to route users to the correct session host and to reconnect them to existing sessions. They should understand where the broker stores connection state, how it behaves during failover or outage, and how session affinity is configured, since these directly affect availability and the reconnection experience.
Security Architects
Architects designing session-based access need to map the boundaries between connection routing, authentication, and authorization in their specific deployment. Because whether the broker authenticates users depends on the product and configuration, architects should confirm which component performs identity verification rather than assuming the broker does, so that access enforcement is not left with gaps.
IAM Engineers
Engineers integrating session brokers with identity providers should clarify, per deployment, whether authentication is delegated to a separate IdP or session host or handled at the broker. This determines how sign-in flows, session state, and reconnection interact with the broader identity architecture.

Inside Session Broker

Session mediation role
A session broker acts as an intermediary that establishes, tracks, and terminates sessions between a requesting principal and one or more downstream resources or services. It typically relies on an upstream identity provider or authentication service to establish who the principal is, rather than performing primary credential verification itself; its focus is on managing the resulting session context.
Session state and context
The broker maintains session-related state such as session identifiers, issuance and expiry timestamps, associated principal identity, and, depending on configuration, contextual signals like device or network attributes. This state is used to correlate subsequent requests to an established session.
Token and credential handling
In many deployments the broker issues, exchanges, or brokers tokens (for example access tokens or session cookies) on behalf of the authenticated principal. Whether these tokens are opaque or self-contained, and whether they are only signed or also encrypted, depends on the specific implementation and profile.
Session lifecycle operations
Typical operations include session creation after an upstream authentication event, session renewal or refresh, idle and absolute timeout enforcement, and session revocation or logout propagation across connected resources, depending on configuration.
Enforcement touchpoints
A session broker commonly interacts with runtime enforcement components. It may consult or coordinate with a policy decision point (PDP) for authorization outcomes and provide session context to policy enforcement points (PEP), though the broker itself is primarily concerned with session management rather than being the authorization decision authority.

Common questions

Answers to the questions practitioners most commonly ask about Session Broker.

Does a session broker authenticate users itself?
Typically not. In most deployments a session broker orchestrates the assignment of a session to a resource after authentication has already occurred, relying on an upstream identity provider or authentication service to verify the principal. The broker generally consumes the result of authentication (for example, a validated token or assertion) rather than performing the credential verification itself. Whether any authentication-related step happens at the broker depends on the specific product and configuration, but treating the broker as the primary authenticator is usually inaccurate.
Is a session broker the same thing as an authorization engine or policy decision point?
No. A session broker's core job is to connect an authenticated principal to an available session or resource instance, not to render authorization decisions in the way a PDP does. In many deployments the broker may enforce or reference policy, such as which resources a user is eligible for, but the underlying authorization decision is typically made elsewhere (for example a PDP consuming attributes from a PIP) and enforced at a PEP. Conflating the broker with the authorization decision function blurs the boundary between session assignment and access decisioning.
How does a session broker typically receive proof that a user has already been authenticated?
In most deployments the broker consumes an authentication result produced upstream, such as a signed token or federation assertion (for example an OIDC ID token or a SAML 2.0 assertion, depending on the environment). The broker validates that artifact, checking signature and relevant claims, before assigning a session. Signature validation confirms integrity and issuer, but note that a signed token is not necessarily encrypted, so confidentiality of any sensitive claims must be handled separately. Exact validation behavior varies by vendor and profile.
What information does a session broker use to select which resource or session to assign?
This varies by deployment. Brokers commonly use attributes or entitlements associated with the principal, such as group membership, role assignments, or resource pool eligibility, to determine which session or backend resource is appropriate. Depending on configuration these attributes may come from a directory (for example via LDAP), from claims in the presented token, or from a separate attribute source. The broker's selection logic should be distinguished from the identity governance processes that provisioned those entitlements in the first place.
How does session broker functionality relate to token lifecycle and re-authentication?
A session broker typically operates within the bounds of an existing authenticated session and its associated tokens. When a session expires or a token is no longer valid, the broker generally cannot silently extend access on its own; re-establishing validity usually depends on the upstream authentication service and any refresh mechanisms in use. Whether the broker triggers step-up authentication or a fresh authentication flow depends on the deployment and the policies configured, not on the broker acting as an authenticator by default.
What should be logged at the session broker for audit and troubleshooting?
In most deployments it is useful to log session assignment events, the identity of the principal associated with each session, the resource or backend selected, and the outcome (success or failure). Because the broker sits between authentication and resource access, its logs help reconstruct which authenticated principal was connected to which resource and when. These records support operational troubleshooting and audit, and are typically distinct from the authentication logs produced by the identity provider and from access-decision logs produced at a PDP or PEP. Exact log fields depend on the product.

Common misconceptions

A session broker authenticates users by verifying their credentials.
In most deployments the session broker does not perform primary credential verification. It relies on an upstream identity provider or authentication service to establish the principal's identity, and then manages the resulting session. Its involvement in authentication is typically limited to consuming or brokering the outcome of an authentication event, not validating knowledge, possession, or inherence factors directly.
A session broker is the authorization decision point that decides what a principal may do.
Session management (authentication-derived session state) and authorization (determining permitted actions) are distinct concerns. A session broker may relay session context to or consult a PDP, but the authorization decision itself is generally made by policy components, not by the broker. Conflating session brokering with authorization enforcement misrepresents the boundary between the two.
Because a session broker issues signed tokens, session data is protected from disclosure.
A token being signed establishes integrity and origin, not confidentiality. Unless the token or session payload is also encrypted, its contents may be readable. Whether tokens are opaque or self-contained, and signed or encrypted, depends on the implementation and profile in use.

Best practices

Clearly delineate the broker's responsibilities: treat it as a session management and mediation component that consumes upstream authentication outcomes, rather than as the primary authenticator or the authorization decision authority.
Integrate the broker with an established identity provider for authentication and with a PDP/PEP model for authorization, keeping identification, authentication, and authorization as separate steps in the access flow.
Enforce both idle and absolute session timeouts, and implement session revocation and logout propagation so that terminated sessions are invalidated across connected resources, depending on deployment capabilities.
Protect session tokens according to their sensitivity: rely on signing for integrity and add encryption where confidentiality of session or token contents is required, since signing alone does not prevent disclosure.
Bind sessions to contextual signals such as device or network attributes where supported, and support step-up authentication by re-engaging the upstream authentication service when higher assurance is needed for sensitive operations.
Log session lifecycle events, creation, renewal, and termination, with the associated principal and timestamps to support auditing, incident investigation, and governance reviews.
Promotional banner for the Penetration Report Template Kit