In this post you will learn about Single Sign-On (SSO) authentication and how to use it for your web apps
Single Sign-On (SSO) authentication is now required more than ever. Nowadays, almost every website requires some form of authentication to access its features and content. With the number of websites and services rising, a centralized login system has become a necessity. In this post, we will study how SSO authentication is implemented for the web. Read on!
The concept of a centralized or linked electronic identity is known as federated identity. Federated identity systems handle several concerns:
The attributes exchange aspect deals with data sharing across different user management systems. For instance, fields such as “real name” may be present in multiple systems. A federated identity system prevents data duplication by linking the related attributes.
Lastly, user management is related to the administration (creation, deletion, update) of user accounts. A federated identity system usually provides the means for administrators (or users) to handle accounts across domains or subsystems.
SSO is strictly related to the authentication part of a federated identity system. Its only concern is establishing the identity of the user and then sharing that information with each subsystem that requires the data. Below, we focus on this crucial aspect of a federated identity system.
Single sign-on (SSO) authentication has become an essential part of accessing websites and applications today. With so many sites requiring usernames and passwords logging in can feel cumbersome. SSO provides a seamless way for users to access multiple applications using one set of credentials.
In this comprehensive guide, we’ll explain what SSO is, why it’s important, and how the technology works. Whether you’re a user looking to better understand SSO or a developer implementing it, you’ll learn the ins and outs of single sign-on authentication.
What is Single Sign-On?
Single sign-on allows users to log in once with a single ID and password to gain access to multiple applications. The credentials are stored and verified by an SSO provider, then connected across all apps integrated into the SSO.
Once logged in to one SSO-connected application, users can navigate seamlessly to others without re-entering credentials The benefit is convenience for users and reduced password fatigue. Administrators also gain efficiency with automated provisioning and deprovisioning across all apps
SSO eliminates the need for multiple usernames and passwords by acting as an intermediary authentication layer. Users log in once, then SSO handles logins across integrated apps.
Why is Single Sign-On Important?
SSO provides many benefits for organizations, developers, and end users:
Improved Security
-
With SSO, users have fewer passwords to remember and change. This reduces unsafe practices like using the same password everywhere or writing down passwords.
-
Administrators can enforce centralized password policies and multi-factor authentication across all applications.
-
Quickly disable access when users leave the organization.
Increased Productivity
-
Studies show users waste time remembering and entering passwords. SSO creates a seamless experience to access apps faster.
-
Employees aren’t locked out of apps when they forget passwords. IT help desks field fewer password reset requests.
Compliance
-
SSO ensures all users meet password policy requirements.
-
Reporting provides audit trails for user access.
-
Standards like SAML, OAuth, and OIDC facilitate compliance.
Development Efficiency
-
Faster implementation of SSO versus building proprietary authentication for each app.
-
Simplified login logic.
-
Leverage standards like SAML, OAuth, and OIDC.
Enhanced User Experience
-
Convenience of single login improves user adoption of new apps.
-
Employees access internal web apps through a common portal.
-
Custom branding promotes consistency.
How Does Single Sign-On Work?
SSO seems like magic to the end user. But how does the technology work behind the scenes?
Single sign-on removes authentication logic from individual apps. Instead, authentication happens via an SSO provider acting as an identity broker.
The SSO provider handles the login process for integrated apps through secure identity federation techniques. Popular standards used include SAML, OAuth, OpenID Connect, and others.
Here are the technical steps of a typical SSO flow:
-
User accesses an application integrated with SSO.
-
The app automatically redirects the user to the SSO provider for authentication.
-
If not already logged in, the user enters their credentials on the SSO provider site.
-
The SSO provider verifies the credentials are correct.
-
The SSO provider generates an authentication token for the user session.
-
The token is sent back to the original app through the user’s browser.
-
The application grants access based on the approved token.
-
When accessing additional apps, steps 2-7 repeat without re-entering credentials.
This simplified flow illustrates the behind-the-scenes authentication handling of SSO. The user logs in once at the identity provider, then seamlessly accesses other apps due to the shared token.
Now let’s explore some key components of SSO in more detail.
SSO Protocols
Single sign-on relies on standard protocols to securely share identity data between the apps and identity provider:
SAML
SAML (Security Assertion Markup Language) is an XML-based protocol used extensively in enterprise SSO. SAML assertions provide authentication and authorization data between identity providers and service providers.
OAuth and OpenID Connect
OAuth 2.0 is an authorization protocol that allows apps to access resources from the identity provider. OpenID Connect is an authentication layer built on OAuth 2.0. Modern SSO solutions often use OpenID Connect.
Proprietary Protocols
Some provider-specific SSO technologies use proprietary protocols. For example, Microsoft ADFS leverages WS-Federation and WS-Trust.
SSO Session Management
SSO solutions must include centralized session management to track logged in users across apps.
Options include setting browser cookies, token-based sessions, or leveraging the sessions built into protocols like SAML and OAuth.
Session length and renewal rules are configured at the SSO provider. Apps defer to the provider.
SSO User Stores
The identity provider needs a user store to check credentials during login. This is typically a directory service like:
- Active Directory
- LDAP
- Database
- Cloud directory
Many SSO solutions support syncing with multiple identity stores.
SSO App Integration
Enabling SSO requires configuring an application’s authentication logic to defer to the identity provider.
Pre-built integrations may be available for common apps like Office 365. Otherwise, standards like SAML and OpenID Connect facilitate custom integration.
Behind the scenes, the app exchanges data with the identity provider through endpoints. For the end user, the process appears seamless.
SSO Access Management
SSO providers centralize access management capabilities for integrated apps:
Provisioning
Automatically create, update, or deactivate user accounts across all apps.
Authorization
Apply granular role-based access policies to apps.
Auditing
Track and report on user access for compliance needs.
These access management features are handled centrally rather than individually within each application.
SSO Deployment Models
Organizations have flexibility when deploying single sign-on:
Cloud-Based SSO
A cloud SSO provider hosts the service. This option has fast setup and is easier to scale. However, some highly regulated organizations prefer on-premises SSO.
On-Premises SSO
Install SSO software internally, with full control by your organization. Can be more complex to deploy and maintain.
Hybrid SSO
Combine a cloud SSO provider for convenience with an on-premises system for legacy apps or added security. More complex but provides flexibility.
Evaluate deployment models based on your apps, security policies, and resources. For many organizations today, cloud SSO makes the most sense.
SSO Use Cases
Now that you understand the SSO fundamentals, where can you apply it? Here are some common use cases.
Workforce Productivity
Employees access dozens of SaaS and web apps daily. SSO allows seamless access to boost productivity.
Customer Identity and Access
SSO for customer-facing web and mobile apps improves conversion rates and loyalty.
B2B Partner Access
Securely provide access to apps for business partners by integrating SSO.
App Development
Accelerate development and improve user experience by implementing SSO in new apps.
IT Systems Consolidation
Consolidate access to architectures like hybrid cloud using SSO as a secure bridge.
Mergers and Acquisitions
Quickly transition users to new systems by leveraging SSO and automated provisioning.
Top SSO Providers
Many solutions exist for implementing SSO. Here are some leading options:
-
Microsoft – Active Directory Federation Services (ADFS) is Microsoft’s enterprise SSO platform. Integrates tightly with Azure AD.
-
Okta – A popular cloud identity provider offering pre-built app integrations.
-
Ping Identity – Provides SSO flexibility with cloud and on-premises deployment options.
-
OneLogin – Cloud SSO focused on ease of use and rapid implementation.
-
Centrify – Specializes in bridging cloud SSO with on-premises Active Directory environments.
-
Auth0 – Developer-friendly SSO designed for modern applications and APIs.
Evaluate the right fit based on your apps, infrastructure, use cases, and development resources.
Get Started with SSO
With password fatigue plauging users and developers, SSO adoption will only grow. Applying SSO best practices positions organizations to improve security, compliance, productivity, and user experience.
Hopefully this guide provided you a comprehensive overview of how single sign-on authentication works. Ready to implement SSO and say goodbye to password chaos? Reach out to leadings SSO providers for more information and next steps.
SSO Authentication with Auth0
If you have been reading about SSO online, you have probably found that there are many different implementations: OpenID Connect, Facebook Connect, SAML, Microsoft Account (formerly known as Passport), etc. Our advice is to choose whatever is simplest for your development efforts. For instance, SAML is deeply entrenched in enterprise developments, so in some cases, it will make sense to pick that. If you think you will need to integrate your development with more than one alternative, dont despair: there are frameworks that allow interoperability between different SSO solutions. In fact, thats one of the things we do at Auth0.Try out Auth0 authentication for free.
You can go and check our docs on Single Sign-On and the Auth0 SSO samples.
If you remember the Typical SSO Scenario diagram we saw earlier, you can see how Auth0 comes to play in the next diagram:
In this case, Auth0 is the Authentication Server and it works as a bridge between different SSO frameworks.
For further information, we invite you to learn more about SSO with our free whitepaper.
Single Sign-On authentication is here to stay. Decentralized systems are becoming more and more common and authentication is an essential aspect of all of them. SSO solves a big problem: how to manage the increasing number of users across a whole ecosystem of applications and services. Frameworks such as OpenID Connect and services such as the one we provide at Auth0 make integrating Single Sign-On into your new or existing applications much easier. If you are implementing authentication for a new application or service, consider integrating SSO from the get-go.
Please enable JavaScript to view the
Single Sign-On (SSO) Authentication
Sooner or later web development teams face one problem: you have developed an application at domain X and now you want your new deployment at domain Y to use the same login information as the other domain. In fact, you want more: you want users who are already logged-in at domain X to be already logged-in at domain Y. This is what SSO is all about.
The obvious solution to this problem is to share session information across different domains. However, for security reasons, browsers enforce a policy known as the same origin policy. This policy dictates that cookies (and other locally stored data) can only be accessed by its creator (i.e. the domain that originally requested the data to be stored). In other words, domain X cannot access cookies from domain Y or vice versa. This is what SSO solutions solve in one way or the other: sharing session information across different domains.
Different SSO protocols share session information in different ways, but the essential concept is the same: there is a central domain, through which authentication is performed, and then the session is shared with other domains in some way.
For instance, the central domain may generate a signed JSON Web Token (JWT), which may be encrypted using JSON Web Encryption (JWE). This token may then be passed to the client and used by the authentication domain as well as any other domains. The token can be passed to the original domain by a redirect and it contains all the information needed to identify the user for the domain requiring authentication. As the token is signed, it cannot be modified in any way by the client.
Whenever users go to a domain that requires authentication, they are redirected to the authentication domain. As users are already logged-in at that domain, they can be immediately redirected to the original domain with the necessary authentication token.
What Is Single Sign-on (SSO)? How It Works
What is single sign-on?
Single sign-on is a federated identity management arrangement. The use of such a system is sometimes called identity federation. Open Authorization ( OAuth) is the framework that enables an end user’s account information to be used by third-party services, such as Facebook, without exposing the user’s password.
What is single sign-on (SSO)?
Single sign-on (SSO) is an authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials. How Does SSO Work? SSO works based upon a trust relationship set up between an application, known as the service provider, and an identity provider, like OneLogin.
Why should you use a single sign-on solution?
A single sign-on solution can simplify username and password management for both users and administrators. Users no longer have to keep track of different sets of credentials and can simply remember a single more complex password. SSO often enables users to just get access to their applications much faster.
What is a single sign-on ID?
This ID, which comes in the form of login tokens, contains information about the user, such as a username or email and password, to allow the service provider to know the connection is from a trusted source. How does single sign-on work?
