Subject: Guidance Needed: Descope Social Login, Cookie-Based Sessions, and Silent SSO for Federated OIDC Flow Hi Descope Team, We are using Descope as the authentication provider for our application TenantPay, and we would appreciate your guidance on aligning our login flows with our silent SSO requirements. Below is a detailed overview of our current implementation, the challenges we are facing, and our expected behavior. 1. TenantPay Authentication Usage We use Descope authentication in two main areas: 1. TenantPay Login / Signup 2. Equifax SSO via OIDC (Federated App) 2. TenantPay Login / Signup – Current Implementation Existing Flow (Frontend-Driven) 1. TenantPay renders a custom login/signup page. 2. A Descope Flow is embedded and hidden on the page. 3. When a user clicks a social login button (e.g., Google), we programmatically trigger the corresponding Descope social login action. 4. The user is redirected to the external identity provider (e.g., Google). 5. After successful authentication, the user is redirected back to the TenantPay login/signup page with an authorization

code

in the query parameters. 6. The Descope Web SDK

onSuccess()

callback is triggered. 7. We generate a refresh token using Descope Web SDK and send it to our backend to retrieve user details. This flow worked correctly when tokens were returned in the SDK response. 3. Silent Login Requirement and Session Management Change To support silent login (i.e., automatically authenticating users who already have an active Descope session), we enabled the following setting: • Session and refresh tokens are managed in cookies (via Project → Session Management settings). After enabling cookie-based session management: • The refresh token is no longer returned in the SDK response body. • As a result, our original frontend-driven login flow stopped working. 4. Updated Login Approach (Backend-Driven Code Exchange) To adapt to cookie-based sessions, we modified the flow as follows: We configure the redirect URL in the Descope Web SDK to point directly to our backend. After successful social login, Descope redirects the user to our backend callback URL with an authorization

code

. 1. The backend exchanges the

code

for tokens. 2. On success, the backend redirects the user back to the TenantPay frontend login page. Issue Observed In this approach, the DS and DSR cookies are not being set on

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

, which prevents silent login from working in downstream flows. 5. Equifax SSO Flow (OIDC Federated App) TenantPay users can access Equifax via SSO using OIDC, implemented through a Descope Federated App. Flow Details 1. The user logs in to TenantPay. 2. The user is redirected to the TenantPay dashboard. 3. The dashboard contains an iframe. 4. The iframe loads an Equifax URL. 5. Equifax redirects the user to the Descope Federated App authorization endpoint. 6. Because this flow runs inside an iframe, we have self-hosted the following repository: https://github.com/descope/auth-hosting 7. A Descope flow (designed by us called federated-login) is shown. 8. This step is skipped if the user already has valid DS / DSR cookies on

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

, which is the desired behavior since we cannot display the Descope UI inside an iframe. 9. After successful authentication (silent or manual), Descope redirects the user back to the Equifax redirect URL with an authorization

code

. 10. Equifax exchanges the

code

for tokens. 11. Equifax validates the

id_token

using Descope’s public JWT keys and renders user details inside the iframe. 6. Expected Behavior • A user logs in or signs up on TenantPay using: ◦ Email/password, or ◦ Social login (e.g., Google). • After successful login: Session cookies (DS and DSR) should be set on the Descope domain (

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

). • The user navigates to the TenantPay dashboard. • The dashboard iframe loads. • The iframe redirects to Equifax. • Equifax redirects to the Descope Federated App authorization URL. • Since the user has an active Descope session: ◦ Descope should silently authenticate the user. ◦ Descope should immediately redirect back to the Equifax redirect URL with an authorization

code

. • Equifax exchanges the code for tokens, validates the JWT, and completes rendering inside the iframe. The silent redirect from Descope back to Equifax is the most critical requirement. 7. Key Configuration Details • Session and refresh tokens are managed in cookies. • Equifax integration uses a Descope Federated App (OIDC). • Authentication must work inside an iframe, requiring silent login support. 8. Assistance Requested We would appreciate your guidance on the following: 1. Does our initial TenantPay login flow need to be adjusted to properly support cookie-based session management and downstream silent SSO? 2. How can we ensure that silent login works reliably, especially for social logins, so that DS / DSR cookies are correctly established on

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

and reused by the Federated App flow? Thank you for your support. Please let us know if any additional information or logs would be helpful. Best regards, Yash Verma

Hey @Yash Verma, to acheive this you need - 1. Session cookie must be set on a custom domain 2. Federated app has to be on the same domain

Hi @Atharva Joshi So, the login/signup flow will be 1. User initiates signup or login and clicks on a social login option 2. User is redirected to the social identity provider via Descope 3. After successful authentication, Descope redirects the user to the configured redirect URL 4. The redirect URL points to our backend callback endpoint 5. Backend exchanges the authorization code for tokens with Descope 6. Backend redirects to the frontend with a success or failure result Could you confirm that this flow is correct? We are using a self-hosted Descope flow at https://staging-auth.tenantpay.com/login/P2wDGPE46LZVXpCYwRZfsMsba5Ni?flow=federated-login (image 1). So, we should set the cookie domain to staging-auth.tenantpay.com (image 2) Is this correct? Could you also please confirm whether Descope is responsible for setting and managing the session and refresh cookies (DS and DSR) on our custom domain staging-auth.tenantpay.com, or if our backend is expected to set these cookies when handling the authorization callback and exchanging the code for tokens?

Yes Descope will set and manage the DS and DSR cookies on your custom domain which you will have to configure under the General tab in Project settings.

Sure Additional details • Company ID = Tenant Pay (C2w4ficDn20dclDxZjmHSenebYEu) • Project ID = Tenant Pay Staging (P2wDGPE46LZVXpCYwRZfsMsba5Ni) • Flow name = federated-login • Federated app ID = descope-default-oidc

Your flow seems right but redirect URL should point to your FE since descope handles exchanging tokens after auth

Ok, got it. Thanks

Hey @Yash Verma Glad to hear the web flow is working for you Regarding the mobile flow, Yes JWTs are not managed in cookies by the SDKs, instead they are handled in Keychain Services for iOS and EncryptedSharedPreferences for Android. Please refer to this doc for handling sessions on mobile For silent auth you can use the /authorize and add

promt='none'

in the end. Refer Doc

Hi @Atharva Joshi Thank you for the clarification. We understand that, on mobile, JWTs are not managed via cookies and are instead stored securely using Keychain Services on iOS and EncryptedSharedPreferences on Android. We have also updated the authorization request to include prompt=none for silent authentication. However, we are still seeking clarity on how Descope determines the active session context on mobile. In the web flow, session state is inferred using the DSR cookie on api.descope.com. On mobile, since cookies are not used and the tokens are stored locally within the platform-specific secure storage, it is unclear how Descope identifies or validates an existing session during a silent authentication request. Specifically: 1. What identifier or mechanism does Descope rely on to determine session continuity on mobile? 2. How does the /authorize?prompt=none request map to an existing session when cookies are not present? 3. Does the mobile SDK implicitly attach any session or refresh token to the request, or is session state derived entirely from the locally stored JWTs? Could you please advise on the underlying mechanism or point us to documentation that explains this behavior in more detail?

1. The session and refresh tokens determine if a session is valid and is ongoing. the exp claim determine how long it will be active 2. The /authorize?prompt=none request should be hit in a scenario when the user's login session already exists to renew access tokens. If the session is expired then the user has no choice but to reauthenticate. 3. The SDK automatically attaches the session token to each request by reading it from the local storage.