All applications share the same HTTP or HTTPS session cookie. This shared session-cookie scenario enables hackers to intervene by using an untrusted application to hijack the session cookie. With the hijacked session cookie, the untrusted application can impersonate the user and access protected web resources.
Unique SSO token is issued to each application or policy agent after the user has been authenticated. The unique SSO token is referred to as a "restricted token." The restricted token is inextricably connected to the application and to the policy agent. Since each user's SSO token is unique for each application or policy agent, the increased security provided by this scenario prevents an untrusted application, impersonating the user, from accessing other applications. More specifically, the restricted SSO token assigned to a user as a part of the user's session is associated with the policy agent that initiated the original redirection for authentication. So all subsequent requests are checked to verify that they are coming from the same policy agent. If a hacker tries to use the same restricted token to access another application, a security violation is thrown.
What makes the restricted token “restricted” is not related to the syntax of the token. The syntax of a restricted token is the same as that of a regular SSO token. Instead, a specific constraint (IP or DN) is associated with the restricted token. OpenSSO Enterprise server checks the validity of the IP or DN before performing any operation using this restricted token. From OpenSSO Enterprise 8.0 Update 1 onwards, you can configure the DN only restriction. The DN only restriction is suitable if the agents are behind the firewall. This constraint is what ensures that the restricted token is only used for an application that a given policy agent protects.