SSO for Web with OpenID Connect

Overview

In this article we go over two typical use cases for SSO on the web using OpenID Connect.

Introduction to Single Sign-On and its Benefits

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 Benefits of SSO

The main benefit of using SSO is that users can move quickly, yet still securely, between applications and services.

Better user experience: with SSO, the user is authenticated for an entire session for all authorized resources. This provides a 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.

Enhanced Security: The user doesn't have to remember different usernames and passwords. Fewer passwords reduce the risk of breaches and phishing. Enterprises can monitor and audit all login attempts through an identity server and can implement stronger security measures, such as multi-factor authentication (MFA), for all users across applications.

Simplified User Management: SSO enables IT teams to control user access to various applications from a single platform, reducing administrative workload and streamlining the processes of user provisioning and deprovisioning.

Reduced IT expenses: When implementing SSO, the number of password resets is decreased, and user management is streamlined, which can significantly cut down on support and administrative costs.

SSO For Web

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.

With SSO for Web, the user runs the first website and signs in, after which the browser receives an SSO cookie. The user then navigates to a second app and is automatically signed in due to the SSO cookie. Each website receives its own tokens with its allowed API permissions, and therefore runs with least privilege.

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 domains, depending on the configuration of the identity server.

Cookie Security

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 do not have the same origin.

Specifically, this means that only the domain that requested some piece of data to be stored can retrieve that data.

The purpose of SSO is to allow cross-domain identity sharing by securely maintaining an SSO session that the domains can share using the OpenID Connect ID Tokens instead of having direct access to the data.

Third Party Cookie Restrictions

SSO cookies use theSameSite=None:property, to enable SSO cookies to work across multiple web domains. However, in recent years, third-party cookie restrictions mean that some SSO flows no longer work reliably. Read more about the behaviors in the Best Practices - OAuth and Same Site Cookies article.

User Experience

With the Curity Identity Server 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 However, due to third party cookie restrictions this only works reliably in all browsers if the web application and the Curity Identity Server share the same parent domain.

The Problem with Iframes

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.

Iframes 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. With the Curity Identity Server you can whitelist the domains allowed to host login screens in an iframe, to avoid opening up clickjacking threats. However, using SSO cookies in iframes may still not work reliably in all browsers.

Conclusion

These days, Web SSO has to deal with both user experience and third-party cookie restrictions that protect user privacy. To implement SSO for multiple web apps in different domains, avoid the use of iframes and use a top level window where the user can see the domain of the Curity Identity Server. This approach reduces usability compared to previous iframe approaches, but enables a reliable SSO solution.

Last updated: 2025-02-11

Curity