When dealing with Single Sign On for Web Applications (Web SSO) the stakeholders involved in offering those applications i.e. developers, architects, application owners and their administrators, tend to care about how to identify and authenticate the end user who is accessing the web application. And in fact that used to be the only thing they really needed to care about in the early days of the web when everything was built and deployed in house. That has changed as time moved along:
- the range of web applications offered by the same business party today is developed by different software development companies and contractors
- that suite of applications is deployed on infrastructure belonging to different administrative domains, e.g. an Infrastructure-as-a-Service provider, a hosting party and/or a data center operator
- those applications are often managed by different parties, e.g. hosting providers, contractors, managed service providers
Now those developments brought along a challenge in Web SSO since the classic solutions were (and some still are) built on leveraging a single cookie across a set of applications. That cookie presents the identity of the user in a verifiable way by consulting a policy server or by verifying a signature. That is all nice and well except that nature of an SSO mechanism that leverages a single cookie that can be used to access different applications works against itself when different parties are involved in offering those applications: suddenly all of those parties can get a hold of that cookie i.e. an application developer could obtain it through modified code, an infrastructure provider could get it from logs or introspection, an application manager could get it from the application itself or a monitoring system.
But since they obtain that cookie (and they can because their application needs it) they can now also turn around and play it against any of the other applications connected to the same SSO system and thus impersonate the end user in those applications! That is an unacceptable risk for banking and financial businesses but in fact for any company with a reasonable security and compliance policy. In addition to being exposed to this risk when leveraging different external parties to offer applications they are also at risk of employees (application administrators) in one business unit turn bad and hijack applications in other business units.
The way forward is as simple as elegant: make sure that every application receives its own token that cannot be used against another application. The security property of such a token that makes the difference here is called “audience”. The “audience” defines who the intended recipient of the token is and in the modern web it is just as important as the “subject” i.e. the authenticated end user. You may know the concept from the SAML and OpenID Connect protocols where those tokens are issued by a central entity called Identity Provider but always target a specific recipient.
All of the above is one more reason (warning, long sentence…) to move away from previous-century, single-domain cookie-based legacy Web Access Management Systems towards modern standards-based per-application token based security!