The rationale for web SSO and how to maximize user experience.
In this article we go over two typical use cases for SSO on the web.
Single sign-on - SSO - is an authentication process that allows users or clients to log in to one domain and thereby be provided automatic authentication to another domain without further interaction.
Single sign-on allows for continuous use of multiple connected independent or related systems or services. The user identity is maintained across the system and the user is assigned roles and permissions according to the different system settings.
The process ensures that the authenticated session is stored and passed seamlessly between involved services in order to provide access, although the user may be asked to provide consent for new resources in some cases.
Since different services may require different authentication mechanisms, single sign-on also ensures that only systems with the same requirements utilize the authenticated session.
The main benefit of using SSO is that users can move quickly, yet still securely, between applications and services.
With SSO, the user is authenticated for an entire session for all authorized resources. This provides better user experience with fewer authentication prompts.
The applications benefit from this since many applications can act as a single application as the user moves back and forth without noticing that authentication is performed silently.
On the web, the typical use for SSO is to allow authentication across multiple web sites. More specifically, the point is to allow a single user to move across domains.
The user’s identity is established by one site, and then that identity is used by other sites as needed. SSO may also mean that identity information can be shared across domain, depending on configuration on the identity server.
The default browser behavior is to implement a same origin policy where cookies and other locally stored information cannot be shared between different domains - the requests for information does not have the same origin.
Specifically this means that only the domain that requested some piece of data to be stored is able to retrieve that data.
The purpose of SSO is to allow cross domain identity sharing, by securely maintaining a SSO session that the domains can share using the OpenID Connect ID Tokens instead of having direct access to the data.
In addition to letting different domains share SSO session, you might also want to allow partners to work cross-domain and cross-organization to provide the user with services and functionality.
OpenID Connect impose certain restrictions on how the login flow will take place between the client and the identity server. The flow needs to be started with a GET request, redirecting the user to the OpenID Connect Provider. This for most cases desirable but when the OpenID Connect Provider and the Web site are provided by the same organization it may be an unnecessary UX drawback.
With Curity it’s possible to run the OpenID Connect and OAuth flows in an iframe, and maintain the feeling that the user never leaves the website.
Iframes can be very useful and even required for a smooth user experience, by making the authentication process feel like an integral part of the website it is authenticating for, and many sites need to be able to show an overlay on the website with the authentication rather than redirecting.
Iframes, when incorrectly handled, can pose significant security risks in various ways. For example, the iframe is trusted by the user, but can serve up content from a different domain. This can cause it to become vulnerable to a number of user-compounded threats. There may also be a risk of cross-site scripting and similar vulnerabilities being aggravated.
They are also susceptible to click-jacking attacks if not implemented properly, letting a malicious attacker overlay a friendly site where the user is clicking, over the iframe, tricking the user to login when it’s not aware.
Curity provides secure iframes. These protect the organization from the potential attacks that can be targeted against framing solutions. With Curity it is not possible to perform click-jacking attacks and it’s not possible to frame the authentication on untrusted domains. This not only solves the issues with iframes, but even adds an additional level of trust since the identity provider now can assert that the frame is never loaded on malicious sites.
With the Curity Identity Server, you get a Single Sign-On solution with all the benefits of the OpenID Connect standard, but also offers expanded features based on these standards, with a clearly implemented Neo-Security Architecture.
The Curity Identity Server does provide the standard OpenID Connect benefits for SSO, but also enables a range of other options that further improve the SSO experience and security.
Since you are sharing the SSO session between domains, it makes sense to also make that clear to the user through a unified user experience. In the Curity Identity Server, this is automatically enabled through the configuration.
In the Curity Identity Server you can define in detail not only how to share the SSO session, but also specify which other data to share, allowing for differentiated security based on which client is making requests.
In the Curity Identity Server, it’s possible to run an OpenID Connect flow in a secure iframe. This means that the frame is only embeddable from the sites that have been pre-configured in the Curity Identity Server. Any other attempt to embed the frame will cause the frame to not load or to break out.
This makes it possible for organizations keep the user on the same site even when authenticating.
Not only does the Curity Identity Server support SSO but it also supports all single logout mechanisms defined in the OpenID Connect standard, giving you the perfect tools for ensuring that SSO is securely cleaned up.
For more information, see the Curity Developer Portal.
Let’s Stay in Touch!
Get the latest on identity management, API Security and authentication straight to your inbox.