SSO between organisations

SSO between organisations

Single-sign-on (SSO) eliminates the need for users to remember and manage multiple sets of credentials. The premise is simple: I have an account at my company. With SSO, I can use the same account for our Microsoft suite, custom-built invoicing system, and many other applications. However, the year is 2025, and SSO can and should extend to different organisations. Let’s dive a bit into what that entails.

What is SSO?

As we’ve already covered, single-sign-on (SSO) is an authentication method that utilises existing accounts and credentials to authenticate a user for any of several related yet independent software systems. SSO in itself is nothing new and has been around since the 1980s (according to Forbes), but it has evolved from working between applications within an organisation to also federate between different organisations and their software systems.

Traditionally, if you only had a single application, SSO wouldn’t have provided much utility. SSO’s value came from multiple applications where a user only had to sign in to one of them and subsequently could access all other applications without signing in. But today, with SSO between organisations, you should have SSO for your applications, even if you only have one. SSO between organisations allows a user from another organisation to use their existing account for your application, so that you gain the same value as traditional SSO between applications.

SSO between organisations (Federation)

SSO between organisations is called federation, and it works by establishing a trusted relationship between the different organisations involved, allowing them to share information securely. This is typically done using a common standard for authentication, such as Security Assertion Markup Language (SAML) or OpenID Connect. It’s what allows your users to use their existing credentials to access your application(s).
Here’s an example of how federation works in practice:

Let’s imagine an employee; we’ll call them Jane. They work for a company that sells tools for home improvement; this is their home organisation. Your business makes said tools and sells them to different home improvement stores. Jane regularly uses your application to order more inventory. Here’s how SSO between their organisation and yours would flow for this use case:

1. Jane enters the website address for your application to order inventory for her store. She clicks “Sign in”.
2. Your application asks your Identity Provider (IDP) if Jane is authenticated.
3. As this is the first time she signs in, the IDP shows her the available sign-in options.
4. Jane doesn’t want to create a new account, so she selects “Continue with Home org” to sign in with her credentials that already exist in her home organisation.
5. Your IDP then checks with Jane’s home organisation IDP if she’s authenticated.
6. If she’s not yet authenticated (which you most likely will be in your home organisation), her home IDP will ask her to authenticate with her existing credentials. (Perhaps through Microsoft or Google, depending on what her organisation uses.)
7. When she’s authenticated, the home IDP sends proof of authentication to your IDP.
8. Your IDP then sends proof that Jane is authenticated to your application.

The only time Jane sees any sign-in UI is when she signs in for the first time. Following sign-ins, when she has a valid session cookie, she’s immediately signed in and redirected to the application.

Federation provides a more convenient and secure authentication method for users, as it eliminates the need for users to remember multiple usernames and passwords and reduces the risk of password reuse or other security issues that may arise from managing multiple sets of credentials.

Trust boundaries

The thing that allows SSO between organisations to work is a set of overlapping trust boundaries that are configured between applications and different IDPs. One between the system in question and the organisation’s IDP, this setup is what everyone with any form of authentication uses. The application uses this boundary to send and receive session cookies, refresh tokens, identity tokens, etc., to authenticate users and send validated API requests.

A similar boundary exists (in the home organisation) between the user (their browser) and their IDP. In this case, the IDP also sends cookies and tokens to the users’ browser to validate and authenticate whenever needed.

The last boundary critical for SSO between organisations is the secure communication between the different organisations’ IDPs via SAML / OpenID Connect or OAuth protocols. This enables the IDPs to share necessary information about the user and cookies so that users from one organisation and applications from another can flow together seamlessly.

Benefits of SSO between organisations

SSO between applications has many benefits: It’s more convenient and secure, and removes the mental burden of remembering passwords from the user. SSO between organisations adds another layer to them:

• Simplified sign-in boosts efficiency & productivity
  Reduced time spent re-entering passwords for the same identity. When users aren’t spending time signing in, they can focus on tasks that bring value instead.
• Decreased attack surface
  With users not having to remember and protect multiple passwords, your application automatically becomes less vulnerable to attacks such as phishing.
• Add value to your application or service
  Add simple SSO integrations to your sales pitch. With Authway, it’s easy to configure a trust boundary with external IDPs, allowing your customers to gain extra productivity and efficiency, which SSO brings between organisations.
• Less support
  When users are fully managed in their home organisation, a lot of support and management tasks are removed from your own organisation. You won’t need to administrate users, and you’ll get a lot less support with password problems from them.
• Forget about account administration
  Use auto-provisioning to automate the entire user lifecycle without complex integrations. Create accounts on first sign-in, update permissions when an employee’s position changes, and remove accounts when a user leaves the organisation.

Common use cases:

Business-to-business (B2B):

SSO between organisations is gaining a lot of traction, and it’s something that we think every business should have in 2025. Different accounts and passwords for each application, supplier, web portal, etc, are and should be a thing of the past.
Become a part of the solution and add value to your application, remove obstacles for your users and automate the entire user lifecycle.
Let your customers use the same sign-in flow as they are used to at their home organisations. Utilise any common enterprise federation such as Microsoft EntraID, OpenID Connect or SAML.

Business-to-government (B2G):

This business area differs a bit more from B2B and B2C because it usually has a lot more requirements for its suppliers or contractors. Usually, there’s already a shared type of identity platform that they need to use, with SSO between organisations, you’ll immediately meet that requirement and have additional functionality for automating the user lifecycle.

We can also see that public sector customers usually have requirements for SSO in their procurement details.

Business-to-consumer (B2C):

Consumers do not have an organisation they belong to, but they usually have a lot of existing accounts, and some of them can be used for SSO. The acceptance among users to re-use accounts from Google, Apple and Microsoft is increasing, and the ease of use on the phones makes more of them choose a social login instead of creating a new username/password.

Take the next step with Auto-provisioning

Automated provisioning of users handles the complete lifecycle of a user, including creating, maintaining and removing a user.

Since Authway is often used in cooperation between organisations, it enables auto-provisioning of users without setting up complex integrations. Because there are no integrations, Authway will create and maintain users just-in-time when a user signs in.

Want to add SSO between organisations for your business? Get in touch!