One password to rule them all, single sign-on (SSO) and password managers posted 3 weeks ago
Password reuse is bad, what can we do about it? Naively, users could use different passwords for different websites, but there are two problems with this approach:
- Users are bad at creating many different passwords.
- The mental load required to remember multiple passwords is impractical.
To alleviate these concerns, two solutions have been widely adopted:
- Single-sign on (SSO). The idea of SSO is to allow users to connect to many different services by proving that they own the account of a single service. This way the user only has to remember the password associated with that one service in order to be able to connect to many services. Think "connect with Facebook" type of buttons, as illustrated below.
- Password Managers. The previous SSO approach is convenient if the different services you use all support it, but this is obviously not scalable for scenarios like the web. A better approach in these extreme cases is to improve the clients as opposed to attempting to fix the issue on the server side. Nowadays, modern browsers have built-in password managers that can suggest complex passwords when you register on new websites, and can remember all of these passwords as long as you remember one master password.
An example of single-sign on (SSO) on the web. By having an account on Facebook or Google, a user can connect to new services (in this example Airbnb) without having to think about a new password.
The concept of SSO is not new in the enterprise world, but its success with normal end-users is relatively recent. Today, two protocols are the main competitors when it comes to setting up SSO:
- Security Assertion Markup Language 2.0 (SAML). A protocol using the Extensible Markup Language (XML) encoding.
SAML is still widely used, mostly in an enterprise setting, but it is at this point a legacy protocol. OpenID Connect, on the other hand, can be seen everywhere on web and mobile applications. You most likely already used it!
While OpenID Connect allows for different types of flows, let's see the most common use case for user authentication on the web via the authorization code flow:
- Alice wants to log into some application, let's say
example.com, via an account she owns on
cryptologie.net(that's just my blog, but let's pretend that you can register an account on it).
example.comredirects her browser to a specific page of
cryptologie.netto request an "authorization code." If she is not logged-in in
cryptologie.net, the website will first ask her to log in. If she is already logged-in, the website will still confirm with the user that they want to connect to
example.comusing their identity on
cryptologie.net(it is important to confirm user intent).
cryptologie.netredirects Alice back to
example.comwhich then learns the authorization code.
example.comcan then query
cryptologie.netwith this authorization code to confirm Alice's claim that she owns an account on
cryptologie.net, and potentially retrieve some additional profile information about that user.
In OpenID Connect (OIDC), Alice (the end-user in OIDC terms) can authenticate to a service
example.com(the relying party) using her already existing account on
cryptologie.net(the OpenID provider). For the web, the authorization code flow of OIDC is usually used. It starts by having Alice request an "authorization code" from
cryptologie.net(and that can only be used by
example.comcan then use it to query
cryptologie.netfor Alice's profile information (encoded as an ID token), and then associate her
cryptologie.netidentity with an account on their own platform.
There are many important details that I am omitting here.
For example, the authorization token that Alice receives in step 2 must be kept secret, as it can be used to log in as her on
Another example: so that
example.com cannot reuse the authorization token to connect as Alice on a different website, the OpenID provider
cryptologie.net retains an association between this authorization token and the intended audience (
This can be done by simply storing this association in a database, or by having the authorization code contain this information authenticated (I explained a similar technique with cookies in chapter 3).
By the way, the proof given to
example.com in step 4 is called an ID token in OpenID Connect, and is represented as a JSON Web Token (JWT) which is just a list of JSON-encoded data.
In OpenID Connect, if Alice wants to log in on
example.comvia her account on another website (an OpenID provider),
example.comeventually needs to obtain what is called an "ID token." An ID token is some user information encoded via the JSON Web Token (JWT) standard. a JWT is simply the concatenation of three JSON-encoded objects. In the picture, the website https://jwt.io lets you decode a JWT and learn what every field stands for. In our browser-based example,
example.comuses TLS to communicate with (and authenticate) the OpenID provider. Thus, the ID token it receives can be trusted. In other OpenID Connect flows (used, for example, by mobile applications) the ID token can be provided directly by the user, and can thus be tampered with. In this case, an ID token contains a signature which can be verified using the OpenID provider's public key.
Authentication protocols are often considered hard to get right. OAuth2, the protocol OpenID Connect relies on, is notorious for being easy to mis-use (see RFC 6819: OAuth 2.0 Threat Model and Security Considerations). On the other hand, OpenID Connect is very well specified. Make sure that you follow the standards and that you look at best practices, this can save you from a lot of trouble.
Here's another example of a pretty large company deciding not to follow this advice. In May 2020, the "Sign-in with Apple" SSO flow that took a departure from OpenID Connect was found to be vulnerable. Anyone could have obtained a valid ID token for any Apple account, just by querying Apple's servers.
SSO is great for users, as it reduces the number of passwords they have to manage, but it does not remove passwords altogether. The user still has to use passwords to connect to OpenID providers. If you're interested to know how cryptography can help to hide passwords, read the rest of this content in my book real-world cryptography.