Too many logins spoil the online experience

If you’re someone who’s ever changed their name, the magnitude of this problem increases exponentially.

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 Single Sign-On).

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.

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 with 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 with 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 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 - 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, and several OpenID Identity Providers such as Google, Facebook and Microsoft are already configured.

More about Anvil

If you’re new here, welcome! Anvil 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