How to Fix AWS Cognito and Azure AD SSO Logout Issues

How Did We Discover the Silent Re-authentication Issue?

While working on a large-scale enterprise workforce management SaaS platform, we encountered a critical security and user experience flaw during the quality assurance phase. The application utilized an AWS Cognito user pool with Azure AD federated as an OpenID Connect (OIDC) identity provider. Authentication was handled via the Cognito Hosted UI utilizing the authorization code flow.

The issue surfaced on shared workstation environments, which are common in manufacturing and retail sectors. User A would log into the application, complete their tasks and click “Logout”. The application successfully deleted the local session and cookies. However, when User B approached the same kiosk and attempted to log in, the application silently re-authenticated the session under User A’s identity. Cognito and Microsoft Azure were returning the first user’s identity without ever prompting for credentials or account selection.

Because the platform validated that the token identity must match the requested user profile, User B was effectively blocked from accessing the system. This behavior presented a significant roadblock for production deployment. When technical leaders hire software developers for enterprise applications, handling the full lifecycle of federated identity management is a strict requirement. This challenge inspired this article to help engineering teams understand the nuances of OIDC session termination across multiple federated domains.

What Is the Architecture and Problem Context?

The business use case required seamless SSO for internal employees via their corporate Microsoft credentials. The architecture relied on AWS Cognito as an intermediary identity broker. The application initiated the login sequence by redirecting the user browser to the AWS Cognito Hosted UI endpoint with the designated Azure OIDC provider.

A standard request looked similar to this:

https://auth.company-domain.com/oauth2/authorize
  ?response_type=code
  &client_id=CLIENT_IDENTIFIER
  &redirect_uri=APP_CALLBACK_URL
  &identity_provider=AZURE_OIDC_PROVIDER

When the user logged out, our frontend destroyed its local authentication state. But this local action had zero impact on the authentication cookies residing in the browser under the AWS Cognito domain and the Microsoft Azure domain. Because OIDC is a browser-based protocol, those external cookies remained perfectly valid. When the next login request fired, Cognito saw its valid session cookie, verified it with Azure (which also saw its valid cookie) and instantly issued a new authorization code for the previous user.

What Went Wrong During Our Initial Mitigation Attempts?

Our engineering team first assumed this was a configuration issue with the OIDC prompt parameters. We attempted several standard fixes, but none resolved the bottleneck.

Attempt 1: Modifying the Prompt Parameters

We appended prompt parameters like prompt=login and prompt=select_account to the Cognito authorize endpoint. There was no effect. AWS Cognito tends to manage its own Hosted UI session state and historically swallows or ignores these prompt parameters rather than passing them dynamically downstream to federated OIDC providers. It never forwarded the request back to Azure AD to ask for identity verification.

Attempt 2: Server-Side HTTP Calls

Next, we tried triggering a server-side HTTP call from our Node.js backend directly to the Azure logout endpoint. We configured the backend to hit the Microsoft OIDC logout URL upon user sign-out. This also failed entirely. The session cookies that authenticate the user to Microsoft exist locally in the user’s web browser, scoped to the Microsoft domain. A server-to-server HTTP request operates in a completely isolated context; it cannot instruct the user’s browser to clear cookies belonging to third-party domains. Organizations often hire cloud security developers for identity management specifically to navigate these types of decoupled browser security constraints.

How Did We Evaluate the Solutions for Total Session Termination?

To ensure a secure environment, we needed a strategy to completely clear the local application session, the AWS Cognito session and the Azure AD session. We considered multiple approaches.

Solution Option 1: Strictly Using Local Session Expiration

We evaluated relying purely on aggressive short-lived tokens and strictly enforcing local application logouts. While this clears the immediate application access, it leaves the SSO session active in the browser. If a user clicked “Login” again before the external cookies expired naturally, they would still bypass the credentials screen. This was deemed insecure for shared devices.

Solution Option 2: Browser Redirect to Cognito Logout Only

We considered redirecting the user’s browser strictly to the Cognito logout endpoint. This successfully destroyed the Cognito session cookie. However, if the user attempted to log in again, they would be routed back to Azure AD. Because the Microsoft session cookie was still active, Azure would silently re-authenticate them and send them back to Cognito, recreating the issue. This was an incomplete fix.

Solution Option 3: Chained Browser Redirects for Full Logout

We concluded that the only architecturally sound method to clear all federated sessions is an orchestrated chain of browser redirects. The user’s browser must sequentially visit the logout endpoint of every identity provider involved in the authentication chain, allowing each provider to clear its respective domain cookies. For businesses looking to hire AWS developers for enterprise architecture, implementing these precise redirect chains is a hallmark of robust system design.

How to Implement a Complete Cognito and Azure AD Logout Chain?

The correct implementation relies on carefully stacking the redirect URIs. We structured the logout flow to move from the Application to Cognito, then to Azure AD and finally back to the Application.

Step 1: Construct the Azure AD Logout URL

First, identify the Microsoft OIDC logout endpoint for your tenant. You must append a post-logout redirect URI that points back to your application’s public landing page.

https://login.microsoftonline.com/YOUR_TENANT_ID/oauth2/v2.0/logout
  ?post_logout_redirect_uri=https://app.company-domain.com/logged-out

Step 2: Construct the Cognito Logout URL

Next, configure the Cognito logout URL. Instead of providing your application’s URL as the final destination, provide the URL-encoded Azure AD logout URL from Step 1 as the logout destination for Cognito.

https://auth.company-domain.com/logout
  ?client_id=COGNITO_CLIENT_ID
  &logout_uri=URL_ENCODED_AZURE_LOGOUT_URL

Step 3: Execution and Validation

When the user clicks “Logout”, the frontend clears local storage and executes a direct window navigation to the Cognito logout URL. The browser hits AWS Cognito, which invalidates the Cognito session cookies. Cognito then reads the logout URI and issues an HTTP 302 redirect to Microsoft. The browser hits Azure AD, invalidates the Microsoft session cookies and reads the post-logout redirect URI. Azure issues a final HTTP 302 redirect, returning the user safely to the application’s unauthenticated landing page.

This ensures that the next time any user clicks “Login”, they are genuinely prompted by Microsoft to select an account and provide credentials.

What Can Engineering Teams Learn from Federated Identity Lifecycles?

Deploying SSO in an enterprise environment requires deep knowledge of protocol limitations and browser security models. When you hire dedicated remote engineers, you should expect them to apply the following insights to identity management architectures:

• OIDC is strictly a browser-based protocol. You cannot terminate federated sessions via backend server-to-server API calls. Cookies belong to the browser and are rigidly isolated by domain.
• Identity brokers abstract complexity but hide parameters. AWS Cognito simplifies multi-tenant federation, but it often strips out dynamic OIDC parameters like prompt selection. Do not rely on identity brokers to forward specific flags natively.
• Chaining is non-negotiable for shared devices. A logout is not complete until every system in the federation chain has explicitly cleared its session state.
• URL encoding is critical. When nesting redirect URLs within other redirect URLs, strict and proper URL encoding prevents query parameter truncation during the redirect hops.
• Test edge cases aggressively. Functional testing often happens in isolated browser profiles. Always test federated identity flows using shared browsing contexts to accurately simulate kiosk or multi-user workstation behaviors.
• Hire backend developers for complex OIDC flows. Ensure your team understands the distinction between local token invalidation, token revocation endpoints and browser session termination. They require completely different technical approaches.

Summary of Securing OIDC Logout Flows

Attempting to clear federated Azure AD sessions via AWS Cognito using backend calls or local token deletion will result in security flaws on shared devices. The only standard-compliant way to enforce a complete sign-out is through sequential browser redirects, ensuring each domain clears its specific cookies. Designing highly secure, user-friendly authentication pipelines requires meticulous planning and execution. If your organization is struggling with complex cloud architecture, identity management or platform security, contact us.

Social Hashtags

#AWSCognito #AzureAD #MicrosoftEntraID #SingleSignOn #SSO #OpenIDConnect #OIDC #CloudSecurity #IdentityManagement #AWS #DevSecOps #Authentication #CyberSecurity #CloudComputing #SoftwareDevelopment