Single Sign On

Single sign on (SSO) is the process of allowing end users to access multiple applications based on their authenticated identity on another application.

In other words, SSO allows login to your app by proxy – the user signs in to a different app, that you trust to vouch for the user’s identity.

So how does single sign on work? Every SSO process involves two parties:

1. Service Provider (SP): the application the user is trying to access
2. Identity Provider (IdP): the application that manages the user’s identity and is responsible for authenticating them

Once a service provider has registered with an identity provider, regardless of whether it's a B2C or B2B flow, most single sign on processes follow more or less the same core steps:

1. End user opts for SSO: For SSO to happen, the end user needs to be indicate in some way that they wish to authenticate via a specific IdP.
2. The SP redirects the user’s browser to the IdP: This redirect contains specific authentication request content that tells the Identity Provider what SP you came from, what information to send the SP, and where to redirect you back to upon success.
3. Enter user credentials: If the user is not already in an authenticated state, they will be prompted to provide their login credentials for the IdP.
4. The IdP redirects the user’s browser back to the SP: Once the user logs in and the IdP has validated the user credentials, the IdP will redirect the user back to the SP, typically with an authentication token. This redirect will contain some sort of information that the SP can then use to validate the response from the IdP, according to some set of trusted rules that are pre-configured.
5. Access = granted: Once redirected, the end user is now in an authenticated state on the SP.

In the case of your application's tech stack, whatever SSO solution you go with – either a 3rd party or in-house – is what facilitates all of these redirects, and allows the communication between the SP and the IdP to take place securely.

Single sign on is in part so popular because it provides security benefits for your application's users and your developers.

Unlike other methods of identity management, an SSO solution saves users from the burden of password management – remembering multiple passwords, navigating cumbersome password reset flows, etc. Research shows most users tend to reuse login credentials, making password security one of the weakest among login methods.

Instead, SSO enables users to prove their identity through another application – ideally one where they actually use a unique, strong password and additional security measures like multi-factor authentication.

For you the app developer, single sign on helps mitigate security risks by storing fewer potentially reused user identities and passwords that could be exploited on your application via a credential stuffing attack. The end result is the same – only authorized users get in – but the means require far less of you and your team.

The SSO flow described above probably seems familiar to you if you’ve ever done (or implemented) ‘Sign-in with Google.’ And for good reason: it’s a form of single sign-on facilitated via the OAuth/OIDC protocol, and most commonly referred to as ‘OAuth.’

But the OAuth isn’t what your enterprise customers are talking about when they ask if you offer SSO authentication.

Instead of using a social account as the IdP, enterprise companies use a “workforce Identity Provider,” which is a company-specific IdP instance that serves as a centralized source of truth on all employees’ identities and the applications they can access. Their employees will authenticate to these applications via a custom Single Sign-On setup (often referred to as an Enterprise Connection, or SSO Connection) that directs to the company’s specific workforce IdP instance.

This centralized source of truth on employee identity information and access, makes it possible for your customer’s IT Admin to quickly and efficiently make changes to profile information, user access and easily do user access auditing through this workforce IdP. Most Identity Providers also offer ways for IT Admins to group employees based on department or seniority to make application assignment, or Role assignment within those applications, even easier.

Role-based access control, typically referred to as RBAC, is an authorization system for controlling access to systems and resources based around the roles of individual users in an organization. With an RBAC model, everyone who holds a certain role is granted the same set of privileges and access.

For any organization with sensitive information or resources, there are two main questions that need to be answered before access is provided to a user:

1. Who is this user? Are they who they say they are? (i.e. authentication / authN)
2. Are they allowed to take this action (i.e. authorization / authZ)

For B2C applications, authorization is typically fairly straightforward as users are just viewing and acting upon their own data. A user can view their history, edit account settings and create/update data. B2C applications can have more complicated authorization considerations, but this typically only happens at scale.

But for B2B applications, authorization is always a core requirement – even at earlier stages of an organization – because the nature of how data is created, accessed, and shared in an organization requires some form of managing access/permissions. Some users will naturally need to be given more privileges than other users to have consolidation of control and manage access across the organization.

RBAC model enables an organization to:

• Increase security posture: Minimizes the risk of unauthorized users from accessing sensitive information or performing unauthorized tasks which minimizes the surface area for potential attacks.
• Simplifies internal workflows and increases flexibility: RBAC grants users the exact access they need for their roles (after it’s configured internally), so IT doesn’t need to manage one-off permissions for each user. This helps streamline managing permissions at scale for handling onboarding, onboarding, role changes, managing 3rd party contractors, and more.
• Handle compliance requirements: RBAC helps improve compliance postures for different certifications (e.g. SOC2, HIPAA, etc.) that have requirements for businesses to protect sensitive information and ensure that critical information is handled according to certain standards.

Stytch supports both Security Assertion Markup Language (SAML) and OpenID Connect (OIDC).

In terms of the difference between these two protocols, they can best be broken down across the following aspects:

1. Adoption: The SAML protocol is the most widely adopted enterprise solution for federated identity. It is commonly used by corporations, banks, healthcare, universities, and governments. After 20 years of use, it is a very mature standard that supports many industries. OIDC is more widely adopted by B2C applications, and as the newer of the two is gaining fast traction among large enterprises such as Google, Microsoft, Paypal, Amazon, etc. It is usually the preferred auth protocol for tech teams who are building new applications today.
2. Language: SAML is an XML-based protocol, whereas OIDC is a JSON-based protocol.
3. Data format: Because SAML is XML-based, the protocol is both very flexible, but also can be quite verbose. That flexibility has the benefit of being able to store lots of information about an end user, but the downside of quickly making the data grow in complexity and size. Consequently, debugging a lengthy SAML assertion can be quite cumbersome. OIDC, on the other hand, uses tokens like JWTs, which are much more lightweight in comparison to SAML security assertions.
4. Security: Due to its maturity, SAML is used by industries that are highly regulated, like banks and healthcare, that need tight security. It is a much more battle-tested protocol compared to OIDC. But, because of SAML’s complexity and bulkiness, it is also prone to development errors and gotchas which can lead to major security breaches. OIDC on the other hand is designed with more current software practices. It’s much easier to encrypt and sign JSON and tokens with JWTs.