As security professionals, we have spent the better part of a decade building the ultimate digital fortress. We deployed FIDO2, phishing-resistant multifactor authentication (MFA), implemented device trust (certificates), and applied user and entity behavior analytics (UEBA) policies. We fancy identity provider (IdP) dashboards, and see the green checkmarks; that allows us to feel safe.
But there is a dangerous misconception lurking in our industry: We often confuse “secure authentication” with “secure access.”
The hard truth is that while we have secured the login event, we have largely failed to secure what comes after it. Strong authentication validates the identity at the moment of login, but it does not protect the integrity of the downstream single sign-on (SSO) sessions.
The great handoff (and why it fails)
To understand the vulnerability, you need to examine how the modern web works.
Picture your perfect identity setup. You require a corporate laptop and a physical hardware security key or authentication token (YubiKey) to log into your IdP (Okta, Microsoft Entra ID, Ping). When a user logs in, your IdP performs a cryptographic handshake nearly impossible to spoof. The front door is secure.
Your security stack includes multiple layers:
- FIDO2 authentication through YubiKey eliminates phishing attacks. The cryptographic keys never leave the device.
- Device trust verifies each login comes from a managed endpoint. Your IdP checks device certificates before granting access.
- UEBA monitors login patterns. UEBA flags suspicious behavior like impossible travel or unusual access times.
- Network context rules block logins from unknown locations or untrusted networks.
- Risk-based authentication steps up verification when UEBA detects anomalies.
- Session policies enforce time limits and require re-authentication for sensitive actions.
Every request requires verification. Every device needs validation. Every user faces continuous authentication checks.
You’ve built a zero trust perimeter. The front door is locked tight.
But once that handshake is complete, your IdP hands off the baton—usually in the form of a SAML assertion (an XML-based trust anchor) or an OpenID Connect (OIDC) token (a JSON-based identity proof) to the application (the Service Provider, or SP), such as AWS, Salesforce, or GitHub. These standards are used to verify user identity and enable SSO across multiple platforms.
At this exact moment, the security model degrades significantly.
- The SP validates the assertion.
- The SP issues its own session cookie to the user’s browser.
- The IdP steps back. The transaction is over.
Anyone who possesses the session cookie gets access. No questions asked. The application sees the cookie and grants entry. An adversary who steals this cookie from your browser bypasses every security control you built at the front door. Possession equals authentication.
Where secure identity controls stop working
This is where information stealer malware thrives. Malware on a compromised device exports the browser’s cookie jar. The adversary takes your AWS or Salesforce session cookie, imports the cookie into their own browser in another country, and refreshes the page.
What happens next:
- Does the service provider ask for the YubiKey again? No
- Does the service provider check the device certificate? No.
- Does your device-bound policy in Okta protect you? No.
You bound the Okta session. You did not bind the AWS session. The adversary walks through the back door despite you securing the front.
The limits of protocol
This is not a vendor failure. This is an architectural reality of HTTP and current federation standards.
Demonstrating Proof of Possession (DPoP), an extension protocol used to secure OIDC tokens, exists to bind tokens to specific devices. Some identity and access management (IAM) providers support DPoP for their own portals, but the downstream SaaS applications do not support it.
Your employees use Slack, Zoom, Atlassian, and AWS daily. All of these applications rely on session cookies or bearer tokens after authentication. If an adversary with the cookie gets access, the application has no way to verify the cookie came from the original device. While it’s technically possible to mitigate this risk by binding cookies to specific devices, geolocations, or other metadata, it’s neither widely implemented by security teams nor widely supported by SaaS applications.
The protocol gap is real. Federation standards hand off authentication to applications. Applications issue their own session tokens. Those tokens are portable by design.
Closing the gap: Defense in depth
Defenders need to verify sessions continuously, not once at login. Here’s how:
Deploy token binding where available
Token binding is not a new concept but adoption has been slow across the industry. Microsoft Entra Conditional Access offers what it calls Token Protection, but the feature only works with Exchange Online, SharePoint Online, and Teams. Tokens are cryptographically bound to the device.
Monitor vendor roadmaps for expanded support. Push your SaaS vendors to implement token binding mechanisms. Ask for timelines.
Shorten session timeouts
Reducing session timeouts for critical applications limits an adversary’s opportunity. Move from 12-hour sessions to 1-2 hour sessions in your service providers. AWS Identity Center, Salesforce, and GitHub all support configurable time-to-live (TTL) values. Having users re-authenticate more often gives adversaries a smaller window to exploit stolen cookies.
Note: If an adversary maintains persistent access to exfiltrate tokens continuously, shorter timeouts provide less protection, making endpoint security and anomaly detection even more critical.
IP pinning eliminates cookie portability
While session cookies are portable, you can make them less useful to attackers by making the network environment non-portable by using a private VPN or Security Service Edge (SSE) solution to enforce network-based access policies at the application level. By configuring AWS to accept traffic only from your VPN or SSE IP ranges. With these controls in place, when an adversary steals a session cookie and attempts to replay it from outside your controlled IP ranges, the request fails immediately.
Monitor for session anomalies
Send your service provider logs to your SIEM. Build detection rules for suspicious session behavior. Look for sessions with multiple IP addresses, different user agents, or impossible geographic locations within short time windows.
Create a lookup table of known good IP addresses from your IdP login events. Update this table hourly. These IPs passed your zero trust controls at authentication. Cross reference this table against your service provider access logs and flag any session activity from IPs not in your known good list.
This detection method works today with your existing tools. You need log aggregation, correlation rules, and response playbooks. Deploy this before waiting for vendors to fix the protocol gap.
Adopt continuous access evaluation
Push your vendors to support the Shared Signals Framework. This standard, from the OpenID Foundation, lets your IdP notify applications in real time when risk is detected; when your IdP sees suspicious activity, it tells AWS to revoke the session immediately and the communication gap between the IdP and the application closes. Okta and Microsoft Entra ID supports this today. Demand it from your SaaS vendors.
Beyond the green checkmark
Don’t be fooled by the green checkmarks on your dashboards. Identity providers secure the login event, they do not secure what happens after. Authentication proves identity once but remember that session protection must be continuous.
These session controls don’t replace your existing security stack. Session protection is an additional layer that addresses the gap between authentication and ongoing access. Shorten your session timeouts, bind sessions to your corporate network, deploy Shared Signals where your applications support it, and treat session integrity with the same rigor you apply to authentication.
The front door is locked; start protecting everything behind it.
