Category: Federation & SSO

Home Realm Discovery

Also known as: HRD, IdP discovery

Simply put

Home Realm Discovery is the step where a system figures out which identity provider should handle a user's sign-in before that sign-in actually happens. In practice, when a user arrives at a login page connected to multiple organizations or identity sources, HRD routes them to the correct one. This is common in federated and business-to-business setups where different users belong to different identity providers.

Formal definition

Home Realm Discovery (HRD) is the pre-authentication process of determining which identity provider (IdP), or which configured connection, is responsible for authenticating a given user. It occurs during the identification phase of an access flow, before the authentication step itself: the relying party or authorization server resolves the user's home realm (for example by email domain, an explicit selector, or configured policy) and then delegates authentication to the matched IdP. HRD is a routing and selection concern, not an authentication mechanism; it does not verify the user's identity, and it is distinct from the subsequent authorization decision. Implementation details vary by vendor and deployment. Some platforms (such as Microsoft Entra ID) express HRD behavior through configurable policies, while others (such as Auth0 and Kinde) map users to specific enterprise connections. The exact matching logic and available discovery methods depend on the specific product configuration.

Why it matters

Home Realm Discovery is the routing decision that makes federated and business-to-business single sign-on usable at scale. When a single login surface serves users who belong to many different organizations or identity sources, something has to determine which identity provider should handle each sign-in before authentication begins. HRD is that step. Get it right and users are transparently sent to their own IdP; get it wrong and a user can be routed to the wrong connection, which typically results in a failed or confusing sign-in experience.

Because HRD operates during the identification phase, before any credentials are verified, misconfiguration tends to surface as routing failures rather than as authentication compromises. Evidence from the Auth0 community illustrates this failure mode: a deployment that fell back to a database connection instead of the intended enterprise connection was described as having failed home realm discovery. This distinction matters for troubleshooting, because an operator who conflates HRD with authentication may look for credential problems when the real issue is which IdP the user was sent to.

HRD behavior is expressed differently across platforms, so teams operating multi-tenant or B2B environments need to understand their specific product's model. Microsoft Entra ID exposes HRD as configurable policy, while Auth0 and Kinde map users to specific enterprise connections. The matching logic and available discovery methods depend on the product and its configuration, which makes HRD a deployment-specific concern that must be validated per environment rather than assumed.

Who it's relevant to

IAM engineers and identity architects

Those designing federated or B2B sign-in flows need to configure how users are routed to the correct identity provider or connection. Understanding that HRD occurs before authentication helps them design predictable routing and avoid fallback to unintended connections, such as a database connection standing in for an enterprise one.

System administrators operating multi-tenant platforms

Administrators managing environments like Microsoft Entra ID, Auth0, or Kinde must know how their specific platform expresses HRD, whether through configurable policy or connection mapping. Because matching logic and discovery methods vary by product, they need to validate routing behavior per deployment.

Support and operations teams troubleshooting sign-in

When users report failed or misdirected logins, teams benefit from distinguishing HRD routing failures from authentication failures. A sign-in that lands on the wrong connection is an identification-phase problem, not a credential problem, and diagnosing it requires examining discovery configuration rather than the authentication mechanism itself.

Inside HRD

Realm (Identity Provider) Selection

The core function of determining which identity provider (IdP) or authentication domain a user belongs to, so the service provider or relying party can route the authentication request to the correct IdP. This is a routing and identification step that precedes authentication, not authentication itself.

Discovery Mechanisms

The methods used to resolve a user's home realm, which typically include user-driven selection (for example a dropdown or IdP picker), email-domain or username-domain matching, IP-range or network-based hints, and persisted cookies from prior sessions. The mechanism chosen depends on deployment context and desired user experience.

Federation Context

HRD operates within federated SSO deployments, commonly built on standards such as SAML 2.0 or OpenID Connect. It sits at the point where a relying party must decide where to send the user before any federation assertion or token is issued.

Routing Outcome

The result of HRD is a redirect or request forwarding to the resolved IdP's authentication endpoint. HRD determines the destination; the actual verification of the principal (authentication) and any subsequent authorization decisions occur at and after the IdP, and are out of scope for HRD itself.

Common questions

Answers to the questions practitioners most commonly ask about HRD.

Does Home Realm Discovery authenticate the user?

No. Home Realm Discovery (HRD) is the step that identifies which identity provider or realm a user belongs to so the authentication request can be routed to the correct IdP. It is part of the identification and routing phase, not authentication itself. The actual verification of the user's identity happens afterward, at the selected home realm's IdP. Treating HRD as an authentication mechanism conflates identification with authentication; HRD only determines where authentication should occur.

Is Home Realm Discovery a feature specific to SAML?

No. While HRD is commonly discussed in the context of SAML 2.0 federation and web SSO, the underlying problem, determining which IdP should handle a given user in a multi-IdP environment, applies across federation protocols, including deployments using OpenID Connect. The mechanisms differ by protocol and vendor, but HRD as a concept is not tied to SAML alone. Specific behavior depends on the standard profile and product configuration.

What methods are typically used to determine a user's home realm?

Common approaches include prompting the user to select their organization or IdP from a list, deriving the realm from the domain portion of an entered email address or username, using a previously stored cookie or preference from an earlier session, and routing based on a URL parameter or vanity/tenant-specific endpoint. Some deployments also use IP address ranges or network context. The available methods depend on the service provider and federation product; not all methods are supported in every deployment.

How can HRD be automated to reduce user friction?

In many deployments, automation is achieved by mapping email domains to specific IdPs so that entering an address routes the user without an explicit selection, or by persisting the user's prior realm choice in a cookie for subsequent visits. Tenant-specific or vanity URLs can also bypass discovery entirely by encoding the realm in the entry point. The degree of automation possible depends on vendor capabilities and how identifiers map to realms; results vary by configuration.

What security considerations apply to email-domain-based HRD?

Domain-based routing generally relies on the domain portion of a user-supplied identifier before authentication has occurred, so the input should be treated as unverified at that stage. Considerations include preventing enumeration of which domains are federated, handling domains that map to multiple realms, and ensuring the discovery step does not leak information about tenant configuration. HRD determines routing only; it does not by itself establish trust in the entered identifier, which is validated during authentication at the IdP.

How should HRD handle users whose identifier does not match any configured realm?

Behavior depends on the service provider's configuration. Common patterns include falling back to a default IdP or a local authentication option, presenting an explicit realm selection prompt, or returning a generic error that avoids disclosing which domains are federated. Designing this fallback carefully matters because overly specific error messages can enable enumeration of configured realms. The exact options available vary by product and deployment.

Common misconceptions

Home Realm Discovery authenticates the user.

HRD is an identification and routing step that determines which identity provider should handle authentication. It does not verify the user's identity; the actual authentication happens at the resolved IdP as a separate, subsequent step.

HRD is a formal protocol defined by SAML or OpenID Connect.

HRD is a deployment pattern rather than a single standardized protocol. It is commonly implemented alongside federation standards such as SAML 2.0 and OpenID Connect, but the specific discovery mechanism typically varies by vendor and configuration.

Email-domain matching is a secure way to establish trust in the correct realm.

Domain- or hint-based routing is a convenience mechanism for selecting an IdP and should not be treated as a security control by itself. Trust is established through the federation relationship and authentication at the IdP, not by the discovery hint used to route the request.

Best practices

Treat HRD strictly as an identification and routing step, and keep it separate from the authentication performed at the resolved identity provider.

Choose discovery mechanisms appropriate to the deployment context, for example email-domain matching for known enterprise tenants or an explicit IdP picker where domains are ambiguous, and document the fallback behavior when no realm can be resolved.

Avoid relying on discovery hints such as email domain or source IP as security or trust decisions, since these can be spoofed and are intended only to route the user to the correct IdP.

Minimize disclosure of realm or tenant existence in discovery responses where possible, to reduce user enumeration and reconnaissance risk depending on your threat model.

Provide a clear, low-friction user experience when user-driven selection is required, and persist a validated prior selection (for example via a cookie) only where it does not weaken security assumptions.

Test HRD behavior across all supported federation profiles (such as SAML 2.0 and OpenID Connect) and edge cases like unknown domains, multiple matching realms, and expired hints to ensure predictable routing.