An SSO primer: what is it, and how does it work?
Tags: webdev, authentication, security, sso
Published: 2022-03-01 17:50:08

## Too many logins spoil the online experience

![If you're someone who's ever changed their name, the magnitude of this problem increases exponentially.](https://anvil.works/blog/img/sso-what-is-it/limes.jpg)

Imagine you run a tech company. Your employees have got a bunch of different services that they want to use - a ticketing system, an internal wiki, an online code store, an HR system - the list goes on. These are all genuinely different services, perhaps owned or managed by different entities, so you can't just lump them all into one big app. That's a _lot_ of accounts per person - and you have to configure them for each new person you hire, every time someones changes their name, or whenever someone leaves the company. If you miss a single account at any of these stages it could be a serious problem. Plus, it's a pain for your employees to have to sign into all of these places every time they clock in for the day. Surely there's got to be a better way!

What if they only had one account, which let them log in to any of these services? Then, each admin action - a name change, a password reset, setting up or closing out accounts - would only need to happen once, in one place. Suddenly, you have a unique and consistent identity for each employee, and a single source of truth for all their details. And, as a bonus, your employees don't have to remember 6 different passwords and jump through a set of login screens every morning.

That's the idea behind SSO (which, appropriately, stands for **S**ingle **S**ign-**O**n).

## How does it work?

SSO depends on the following principle: there is some central entity that manages your identity, and is able to verify that you are who you say you are. Then, other services delegate their authentication to that central identity. The authentication flow goes as follows:

* You visit your web service of choice.
* That web service sends you to your SSO identity provider's website, where you log in (if you're not already logged in).
* The identity provider sends you back to the web service, along with some token to prove your identity.
* The web service derives your identity from that token (either cryptographically, or just by asking the identity provider).
* The web service then trusts that you have rightfully authenticated as that identity, because they trust the identity provider.

In order to set this up, a relationship between that web service and the identity provider needs to be established *before* the web service will trust the identity provider to authenticate users, and so that the identity provider knows what's going on when it gets an authentication request from the web service.

![By the grace of SSO, Anvil apps can trust Google to authenticate users for them.](https://anvil.works/blog/img/sso-what-is-it/michael-scott.jpg)

Once you've set up a relationship between your web service and a central identity provider, any user that has an identity managed by that provider can use it to log in to your web service. If they're already authenticated that identity provider, your web service will be able to authenticate them without any active input from the user. If the user _isn't_ already authenticated the identity provider, they'll be prompted to do so, and this authentication is the aforementioned Single Sign-On.

By this mechanism, one identity managed by one service can be used subsequently to authenticate the user with multiple services - _without_ needing those services to store or verify user credentials directly. Convenient!

## What are the benefits?

Obviously, it massively reduces user friction. Constantly having to log in to services is a pain, and using a central provider to manage identities means you don't end up with a proliferation of passwords to forget.

On the business and administration side, it means a lot fewer password reset requests for the IT department to handle, and when somebody needs to change some aspect of their identity - for example, a name change - it only needs to happen in one place. When a new user joins the organisation, or an existing one leaves, there's only one account to worry about, which reduces administrative overhead _and_ the opportunity to leave stale accounts hanging around as a security risk.

When it comes to security, you might think that a single set of credentials is far riskier than multiple - after all, they only need to get stolen once, right? However, when done right, SSO can actually _reduce_ risk. By removing the need for multiple sets of credentials and abstracting the process away from the user, it decreases the viability of several common attacks; for example, imagine one of these web services experiences a security breach. You now don't have to worry about someone stealing your users' passwords and attempting to use them elsewhere, because that web service never saw or needed your users' passwords in the first place.

SSO also makes [two-factor authentication](https://anvil.works/blog/two-factor-auth-with-hardware) much more attractive as a prospect, since you only have to do it in one place to see the security benefits across all your services. Moreover, if you delegate your identity management to something like Google, you can rely on _their_ security engineering budget rather than yours. This means getting access to security features like 2FA (with minimal setup), and [risk-based authentication](https://riskbasedauthentication.org/) - which smaller service providers will be hard-pressed to set up.

## SSO isn't a technology, it's a goal

This is all a bit abstract, and that's because SSO, as a standalone concept, is just that; a concept. In my next couple of blog posts, we'll dive into the two most popular technologies used to implement it - SAML and OIDC - and take a closer look at how they work.

Anvil apps come with several ready-made options for SSO - you can configure a SAML-based relationship with any Identity Provider [with no fuss](https://anvil.works/beta-docs/integrations/saml), and several OpenID Identity Providers such as [Google](https://anvil.works/beta-docs/integrations/google/authenticating-users), [Facebook](https://anvil.works/beta-docs/integrations/facebook/linking-facebook-and-anvil) and [Microsoft](https://anvil.works/beta-docs/integrations/microsoft/microsoft-single-sign-on) are already configured.

## More about Anvil

If you're new here, welcome! [Anvil](https://anvil.works) is a platform for building full-stack web apps with nothing but Python. No need to wrestle with JS, HTML, CSS, Python, SQL and all their frameworks – just **build it all in Python**.

[Try Anvil for free!](https://anvil.works/build)