Hi @operations4
Welcome to the Auth0 Community!
You have a SPA + API architecture with Auth0 as the identity provider. Your Auth0 tenant is federated with a third-party OAuth/OIDC authorization server, and you act as the IdP. Users successfully authenticate to your Auth0 application, but when they click a button to access a federated third-party service for the first time in a session, they are redirected to Auth0's login page and required to re-authenticate. After this first re-authentication, SSO works seamlessly for the remainder of the session.
The issue is that the Auth0 session cookie is not being recognized or passed on the first federated authorization request. This is typically caused by one of three factors: missing prompt=none parameter, session cookie scope/domain mismatch, or a timing issue with when the session cookie is established.
[Root Cause]
Auth0 maintains a centralized session on the Auth0 domain (e.g., your-tenant.auth0.com). When a user logs into your SPA via Universal Login, Auth0 sets a persistent session cookie on the Auth0 domain. On subsequent authorization requests, this cookie should be automatically included, allowing Auth0 to recognize the user without prompting for credentials again.
However, in your federated scenario, the first authorization request to the third-party service may not be including the prompt=none parameter, or the session cookie may not be properly scoped. This causes Auth0 to treat it as a new authentication request and display the login page. After the user re-authenticates, the session cookie is properly established and subsequent requests work correctly.
The key differences between your application session and the Auth0 Authorization Server session are:
- Application Session (your SPA): Stored in your SPA's local storage or session storage; contains the access token and ID token
- Auth0 Authorization Server Session: Stored as a persistent cookie on the Auth0 domain; recognized by Auth0 to skip the login prompt on subsequent authorization requests
When you redirect to the federated third-party service, your application session is not automatically transferred. Only the Auth0 session cookie matters. If the cookie is not present or not recognized, Auth0 will prompt for login.
[Solution]
Step 1: Verify that prompt=none is NOT being used on the initial federated request
When initiating the federated flow for the first time, do NOT include prompt=none. This parameter tells Auth0 to use the existing session without showing the login page, but if the session is not yet established, it will result in an error instead of showing the login page. This is also mentioned on our support site where a Login Session Does Not Persists.
Correct approach for first-time federated access:
// First access to federated service - allow login prompt if needed
window.location.href = `https://your-tenant.auth0.com/authorize?
client_id=${clientId}&
response_type=code&
redirect_uri=${redirectUri}&
scope=openid profile&
audience=${audience}`;
// Note: NO prompt=none parameter
Step 2: Verify that the Auth0 session cookie is being set with correct scope
After the user logs into your SPA, verify that the Auth0 session cookie is present and properly scoped:
- Open browser DevTools → Application → Cookies
- Look for cookies on the Auth0 domain (e.g.,
your-tenant.auth0.com)
- Verify the cookie is not marked as "HttpOnly" (it should be accessible to JavaScript for debugging)
- Check the cookie's "SameSite" attribute — It should be set to
None with Secure flag if the federated service is on a different domain
If the cookie is missing or has SameSite=Strict, it may not be sent when redirecting to the third-party service.
Step 3: Ensure your SPA is using the Auth0 SDK correctly
If you are using the Auth0 React SDK (or similar), ensure you have configured it to use persistent sessions:
import { Auth0Provider } from "@auth0/auth0-react";
<Auth0Provider
domain="your-tenant.auth0.com"
clientId="your-client-id"
redirectUri={window.location.origin}
useRefreshTokens={true} // Enable refresh tokens for persistent sessions
cacheLocation="localstorage" // Store tokens in localStorage
>
<App />
</Auth0Provider>
Step 4: Use silent authentication to validate the Auth0 session before redirecting
Before redirecting to the federated third-party service, use silent authentication to ensure the Auth0 session is active:
// React SDK example
const { getAccessTokenSilently } = useAuth0();
const handleFederatedAccess = async () => {
try {
// This will use the existing Auth0 session if available
const token = await getAccessTokenSilently({
audience: "your-api-identifier"
});
// If successful, the Auth0 session is active
// Now redirect to federated service
window.location.href = `https://your-tenant.auth0.com/authorize?
client_id=${clientId}&
response_type=code&
redirect_uri=${redirectUri}&
scope=openid profile&
audience=${audience}`;
} catch (error) {
// Session not active; user will be prompted to login
console.log("Auth0 session not active; redirecting to login");
window.location.href = `https://your-tenant.auth0.com/authorize?
client_id=${clientId}&
response_type=code&
redirect_uri=${redirectUri}&
scope=openid profile&
audience=${audience}`;
}
};
If you are experiencing issues with silent authentication not working within your application, I would recommend researching more about the getAccessTokenSilently method Not Extending Auth0 SSO Session Idle Timeout When Using Refresh Tokens.
Step 5: Verify federated service is configured to accept Auth0 as IdP
Ensure that the third-party service is properly configured to recognize Auth0 as a valid identity provider:
- Verify the redirect URI — The third-party service must have your Auth0 tenant's redirect URI registered (e.g.,
https://your-tenant.auth0.com/login/callback)
- Verify the client credentials — The third-party service must have the correct client ID and secret for Auth0
- Check the OAuth/OIDC configuration — Ensure the third-party service is using the correct authorization endpoint and token endpoint
Step 6: Check Auth0 tenant settings for session configuration
Navigate to Auth0 Dashboard → Settings → General.
Verify the following settings:
- Inactivity Timeout: Set to an appropriate value (e.g., 7 days). If set too low, the session may expire before the user accesses the federated service.
- Require login after: Ensure this is not forcing re-authentication on every request
- Seamless SSO: Verify this is enabled (if using Universal Login)
Step 7: Implement state parameter handling
You mentioned you haven't implemented state parameter handling yet. This is critical for security and can also help with session management:
// Generate a random state parameter
const generateState = () => {
return Math.random().toString(36).substring(2, 15);
};
const state = generateState();
sessionStorage.setItem('auth_state', state);
// Include state in authorization request
window.location.href = `https://your-tenant.auth0.com/authorize?
client_id=${clientId}&
response_type=code&
redirect_uri=${redirectUri}&
scope=openid profile&
audience=${audience}&
state=${state}`;
// On callback, verify state matches
const urlParams = new URLSearchParams(window.location.search);
const returnedState = urlParams.get('state');
const storedState = sessionStorage.getItem('auth_state');
if (returnedState !== storedState) {
throw new Error('State parameter mismatch; possible CSRF attack');
}
Why Re-Authentication Works on Subsequent Accesses:
After the first re-authentication, the Auth0 session cookie is properly established on the Auth0 domain. On subsequent federated requests, the browser automatically includes this cookie in the request to Auth0, allowing Auth0 to recognize the user without prompting for login. This is the expected SSO behavior.
The fact that it works after the first authentication suggests that:
- The federated service configuration is correct
- The Auth0 session cookie is being set correctly after authentication
- The issue is specifically with the initial session recognition, not the federated flow itself
We hope this resolves your SSO session recognition issue. If the problem persists after following these steps, please contact Auth0 Support with the debugging information from the steps above, including HAR files of the authentication flow and Auth0 logs showing the initial federated request.
Kind Regards,
Nik