Hi Descope Team, I'm reaching out regarding an issue with SAML IdP-initiated SSO where an existing Descope session is not being recognized, causing users to be redirected to the login flow on every attempt. --- OUR SETUP • Descope acting as IdP for a Generic SAML Application • Service Provider: * • SP ACS URL: ** • SP Entity ID:** • IdP Certificate: Shared with and installed by the SP • Force Authentication: Disabled • React frontend using @descope/react-sdk with AuthProvider --- WHAT WE ARE TRYING TO ACHIEVE User logs in to our React app via Descope. When they click "Open Benefits Junction", we want them to land on benefits junction page already authenticated — with no second login prompt. --- WHAT WE TRIED 1. IdP-Initiated URL directly Calling the IdP-initiated URL directly from React: https://api.descope.com/v1/auth/saml/idp/initiate?app=<APP_ID> Result: Redirects to Flow Hosting URL (login page) every time, even with an active session. 2. Force Authentication disabled Confirmed Force Authentication is turned OFF in the Descope Console. Result: No change — still redirects to login flow. 3. sessionTokenViaCookie={true} in AuthProvider Result: No change — cookie not recognized cross-site due to SameSite=Strict policy. 4. POST to /v1/auth/session to plant session cookie Result: Failed with error E011006 — "The path /v1/auth/session is invalid or doesn't support POST requests". 5. generateEmbeddedLink + magicLink.verify() via Java backend Used Management SDK to generate a server-side session (sessionJwt + refreshJwt), stored tokens in localStorage, then called the IdP-initiated URL. Result: Descope still does not recognize the session and redirects to the login flow. 6. Java backend proxy redirect Validated session server-side, extracted email, appended login_hint, and used HttpServletResponse.sendRedirect() to the IdP-initiated URL. Result: Partial — login_hint pre-fills the email but the flow still runs. --- ROOT CAUSE WE IDENTIFIED We believe the issue is that Descope's session cookie is set with SameSite=Strict on api.descope.com. When the user navigates from our app domain to api.descope.com, the browser does not send the cookie cross-site, so Descope sees no active session and runs the full login flow. We understand the custom domain setup (CNAME to cname.descope.com) is the recommended fix, but we need to confirm if there is any other supported mechanism. --- OUR QUESTIONS 1. Is there an API endpoint where we can pass the SAML app ID + user info (email / user ID) and receive back a pre-authenticated SSO redirect URL — without requiring the browser flow? 2. Is there a supported query parameter (e.g. session_token=, ds=) that can be appended to the IdP-initiated URL so Descope recognizes an existing session server-side? 3. Are there any other approaches we may have missed? Thank you for your time. Happy to provide additional details, logs, or a screen recording of the issue.

Root Cause Confirmed Your analysis is correct. Descope's session cookies are set with

SameSite=Strict

on

<http://api.descope.com|api.descope.com>

. When navigating from your app domain to

<http://api.descope.com|api.descope.com>

, browsers don't send the cookie cross-site, causing Descope to see no active session. Solutions 1. Custom Domain (Recommended) Set up a custom domain with CNAME pointing to

<http://cname.descope.com|cname.descope.com>

(US) or

<http://CNAME.euc1.descope.com|CNAME.euc1.descope.com>

(EU) . This ensures session cookies work across your domain.

# DNS Configuration
<http://auth.yourapp.com|auth.yourapp.com> CNAME <http://cname.descope.com|cname.descope.com>

Configure in Descope Console under Project Settings > Custom Domain. 2. Alternative Approaches Unfortunately, there are no supported query parameters or API endpoints to bypass the browser session requirement for IdP-initiated flows. The IdP-initiated URL must validate an existing browser session . 3. Workaround Options • Use SP-initiated SSO instead — redirect users to your app's login page, which then initiates SAML authentication • Implement a server-side proxy that handles the SAML initiation with proper session management • Consider switching to OIDC if your SP supports it, as it may offer more flexibility The custom domain setup is the only supported solution for your IdP-initiated SSO scenario with existing sessions. Refresh Token Storage in Project | Descope Documentation IdP-Initiated SSO Configuration | Descope Documentation

We are currently unable to configure a custom domain. Could you suggest an alternative approach? Is there an API available where we can send the SAML App ID, username, and a refresh token to Descope for validation, and then receive a redirect URL with a valid authenticated session?

No Direct API Solution Unfortunately, there's no API endpoint that accepts SAML App ID + username + refresh token to generate an authenticated redirect URL. The SAML

/v1/auth/saml/authorize

endpoint exists , but it requires an existing browser session. Alternative Workaround Since custom domain isn't feasible, consider this server-side approach: Backend Proxy Solution

// Your backend endpoint
<http://app.post|app.post>('/saml-proxy', async (req, res) => {
  const { userId, samlAppId } = req.body;
  
  // 1. Generate embedded link for user
  const embeddedResp = await descopeClient.management.user.generateEmbeddedLink(
    userId, 
    { timeout: 300 } // 5 minutes
  );
  
  // 2. Create redirect URL with embedded token
  const redirectUrl = `<https://yourapp.com/saml-handler?t=${embeddedResp.token}&app=${samlAppId}`;>
  
  res.json({ redirectUrl });
});

Frontend Handler

// /saml-handler page
useEffect(() => {
  const urlParams = new URLSearchParams(window.location.search);
  const token = urlParams.get('t');
  const appId = urlParams.get('app');
  
  if (token) {
    // Verify embedded link to establish session
    descopeClient.magicLink.verify(token).then(() => {
      // Now redirect to IdP-initiated URL with session
      window.location.href = `<https://api.descope.com/v1/auth/saml/idp/initiate?app=${appId}`;>
    });
  }
}, []);

This uses the Management SDK's

generateEmbeddedLink

function to create a server-side session token, then verifies it client-side to establish the browser session before SAML initiation. Creating SAML redirect URI | API Reference | Descope Documentation Generate Embedded Link | API Reference | Descope Documentation

For this SAML redirect solution, do we need the tenant ID? Is there any configuration required in the tenant setup?

Tenant Configuration Requirements For the SAML redirect solution: 1. Tenant ID is NOT required for

generateEmbeddedLink

The Management SDK's

generateEmbeddedLink

function works at the project level and only requires the user's

loginId

(email/phone/userId) . No tenant ID needed. 2. No special tenant setup required The embedded link approach bypasses tenant-specific SAML configurations. It creates a project-level session that works across all tenants. Updated Implementation

// Backend - no tenant ID needed
<http://app.post|app.post>('/saml-proxy', async (req, res) => {
  const { userEmail, samlAppId } = req.body;
  
  // Generate embedded link (project-level, no tenant required)
  const embeddedResp = await descopeClient.management.user.generateEmbeddedLink(
    userEmail, // loginId - can be email, phone, or userId
    { timeout: 300 }
  );
  
  const redirectUrl = `<https://yourapp.com/saml-handler?t=${embeddedResp.token}&app=${samlAppId}`;>
  res.json({ redirectUrl });
});

Key Points • Embedded links work at the project level, not tenant level • User sessions established via embedded links work with any SAML application in your project • No tenant-specific SSO configuration needed for this workaround The solution bypasses the tenant SSO layer entirely by establishing a project-level session first. Verify Token | API Reference | Descope Documentation SSO Management API | Descope Documentation

I have valid token, i need to set cookies for

<http://api.descope.com|api.descope.com>

how to do?