Feature Request: Support for SAML Scoping in signInWithSSO to bypass IdP discovery (WAYF)

[IdrisCelik]

AUTH-921

Description

Sorry for the influx of issues haha. I found another issue limiting flexibility of SAML or even making SAML impossible to use.

Currently, the supabase.auth.signInWithSSO method for SAML providers initiates a standard login flow. In many real-world scenarios, especially with federated identity systems (common in enterprise, government, and education), this flow first directs the user to a central discovery service, often called a "Where Are You From?" (WAYF) screen. On this screen, the user must manually search for and select their home organization (the Identity Provider or IdP) from a list that can contain hundreds or even thousands of entries.

This creates significant user friction, particularly for multi-tenant applications where the user's organization is already known to the application. The SAML 2.0 protocol provides a standard mechanism called Scoping to solve this. By including a <Scoping> element in the initial AuthnRequest, the Service Provider (Supabase) can "hint" to the federation which IdP the user should be authenticated against. This allows the federation to bypass the discovery screen entirely and send the user directly to their organization's login page, resulting in a much smoother and faster authentication experience.

Without the ability to specify the IdP, the current SAML implementation in Supabase is less effective in these federated environments, forcing a suboptimal login experience on all users.
Even worse, scoping is requered for some hubs, making Supabase not even a option anymore.

Suggested solution

This is the preferred approach due to its simplicity, safety, and clear intent. It would involve adding a new, optional property to the options object of signInWithSSO.

How it would work:

A developer could pass the entityID of the target Identity Provider directly:

const { data, error } = await supabase.auth.signInWithSSO({
  provider: 'saml',
  options: {
    redirectTo: 'https://my-app.com/dashboard',
    // New option to specify the target Identity Provider
    providerId: 'https://idp.my-university.edu/saml'
  },
})

When this providerId is present, the Supabase Auth backend would generate a SAML AuthnRequest containing the standard <Scoping> element:

<samlp:AuthnRequest ...>
  <saml:Issuer>...</saml:Issuer>
  <samlp:NameIDPolicy ... />
  
  <!-- This block is added based on the providerId option -->
  <samlp:Scoping>
    <samlp:IDPList>
      <samlp:IDPEntry ProviderID="https://idp.my-university.edu/saml" />
    </samlp:IDPList>
  </samlp:Scoping>
  
</samlp:AuthnRequest>

Advantages of this approach:

• Simple & Secure: The API is straightforward and prevents developers from injecting arbitrary or malformed XML.
• Developer-Friendly: It directly solves the primary use case with a single, easy-to-understand option.
• Low Maintenance: The implementation on the backend is well-defined and constrained.

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.