Why Single Sign On Sucks

A month ago I tweeted about my annoyance with SSO or Single Sign On. While single is in the name, I'm required to “single sign on” multiple times a day. I’m not the only one; the tweet went viral with over 25k likes and 2 Million impressions. The tongue-in-cheek tweet created a lot of fun responses and more rage against SSO user experience than I expected. SSO was meant to solve password fatigue but we got something worse.

To provide an example, this is what it looks like on a daily basis if I want to login to Github.

During this flow, I first login to Github, Tap my 2FA Token, then I'm required to login again using Okta, tap my MFA token, enter my password and then I’m into Github.

Since Teleport uses Okta as an identity provider, there is an extra step for most apps. As new employees join Teleport, they are added to our HR software, which pushes employee attributes to Okta for use in Attribute Based Access Controls (ABAC). Okta then acts as our identity and access management solution to provide federated access to all systems. Dynamic directory groups are used to provision access to apps based on an employees role. This creates a very efficient onboarding process and an even more swift offboarding. The offboarding procedure is so efficient that there is little change to send the final goodbye message, as all of our Okta Directory is automated using Terraform.

Why do we need to SSO 43 times a day?

In an ideal world, I would log into the computer, login to my SSO solution, and then go about my day's work, accessing multiple apps without having to see a login form or doing a redirect dance again.

There are a few problems that mean that this isn’t a reality. The tl;dr is that because each app controls the login process, and different apps have different architectures, having a standardized flow that works across all apps is very challenging. There are some existing solutions to address this, but all have their shortcomings.

To understand why SSO is such a pain at a deeper level, we to understand how an application integrates with identity-providers (IdPs), to create the single sign-on flow. Application developers have to integrate using SAML or OIDC, for Authentication or AuthN. It’s then up to the app to decide what to do with the user identity and resulting token, and this is where it gets a bit more complicated…depending on the use case.

SSO Authentication for Web apps: Server & client side sessions

For traditional web applications, authentication logic happens on the server. For a Rails app, for example, devs can use the devise_saml_authenticatable which will create a session cookie that'll last one browser session with a defined timeout, with some extra client-side logic to fix for long client timeouts.

SSO Authentication Web apps: JavaScript apps / SPAs

Single Page Applications (SPAs) are web applications that dynamically rewrite the page while getting data from the web server. A ‘true’ page refresh never happens since all HTML, JavaScript and CSS is loaded in a single page load*. Adding authentication and session management comes with a myriad of client-side issues. While it’s possible to create cookie with credentials, this should be avoided due to all the possibilities of CSRF Attacks. In short, Cross-Site Request Forgery (CSRF) attacks allow an attacker to forge and submit requests as a logged-in user to a web application; this issue can be fixed by adding tokens and limiting same-site cookies. What does this mean for our SSO app? Due to the mechanisms, you’ll need to re-auth if logging in from a different browser, or again if your session has expired.

SSO Authentication for CLI apps

The next category of ‘applications’ are CLI tools. For me, Heroku pioneered the concept of mainly interacting with the product via the terminal. The heroku cli was the app; heroku.com just provided a nice dashboard and cost breakdown for dynos. As with all other services, that CLI tool has to get credentials. Once SSO is enabled, developers will be greeted by an experience similar to the image below. You’ll login, and a SSO authorization page will pop up, once authenticated. I can close my browser since the credentials are now available locally. For AWS this is in ~/. aws/sso/cache but as with all caches, these credentials are valid from 1hr to 12hrs.

SSO Authentication for Mobile apps

Mobile apps are almost the same as web apps but can provide a few benefits and a few challenges. A pro of mobile apps is the ability to move to passwordless by leveraging biometrics, FaceID for example. The problem often faced is when trying to integrate with a hardware token, you need to make sure you have an NFC Yubikey to use the token for both desktop and web apps.

An ‘honorable mention’ for mobile app SSO is QR Login, which makes it super easy to quickly login to discord on a bunch of machines. This lets me quickly access discord on a Work Mac, Linux Box and Windows Machine seamlessly.

SSO Authentication for Web app with multiple orgs. E.g. AWS Console

At Teleport we follow the best practice of using different AWS organizations to provide isolation of environments. This is a best practice for secure access to aws, and we cover it in detail in Episode 12 of Access Control with LVH.

The main reason behind the multiple accounts thing is that because we found that, in many cases, it's really hard to get people to do a great job at managing AWS IAM, like people just write a particular permission. It's super broad, and they just keep adding infrastructure and infrastructure and infrastructure. And before you know it, that ability to read from every S3 bucket is suddenly far more terrifying than it was when you agreed to it … Because you're already thinking about things like, "Am I —" hopefully you're thinking about whether you're in dev or prod before you drop the tables. So you're already thinking about that. So that much of an extra — it's a lot of extra mental bandwidth that's being asked for. But then on the flip side, from a security perspective, I have an extremely strong guarantee that things are going to stay separate. And similarly, if an auditor comes and asks, then we can say, "We don't have to talk. We don't have to spend hours talking about AWS IAM policies." We can just say, "Yeah, separate accounts," like completely separate off domains. Multiple AWS accounts is such a no-brainer.

In practice, the UX can be a bit jarring. When you start a session on an AWS account, that tab becomes logged out if you login to a new account. I would file this UX as both a bug and a feature, but it’s darn annoying if you’re doing a lot of work across accounts.

SSO Solutions and Improvements ?

While I like a good rant, I hope that in 2-5 years most of this blog post will be irrelevant, and this is why.

Browser-based solutions

Google has provided an interesting hack to the session dance. For example I’m able to stay logged into both my Work and Personal Gmail by using different profiles. There is little information on the feature apart from this brief page and while it does reduce some of my re-login dance, it’s easy to be cynical and assume it’s just to better track my work vs personal life.

Device-based solutions

For organizations that really want tightly locked devices, issuing Chromebooks for work purposes might be the best for security, and when combined with Advanced Protection that enforces multi-factor authentication has become the de-facto for helping secure elections, but this doesn’t fix the login once and don’t SSO again. The industry has made some progress with cross-device trust with AirDrop, and some copy-and-paste functionality with Universal Control but these solutions are vendor-specific and limited in what they can do.

Passwordless

Passwordless authentication is a method that lets a user log into a computer without having to remember a password or another knowledge-based secret. It uses a combination of Ownership Factors (something the user has) and Inherence Factors (something the user is). For example, I can be in possession of a hardware token (something I have) and have my fingerprint (something I am) to get access to a system. The branding of passwordless is confusing, and it doesn’t mean the death of passwords or password managers just yet.

A few examples of this are Touch ID, using the secure-enclave combined with a fingerprint. Microsoft's Windows Hello, using a Trusted Platform Module (TPM) combined with facial recognition. Windows Hello requires a webcam with an IR sensor to let it work in all conditions. One benefit of Facial recognition is the convenience of authentication, but this can have negative consequences if you don’t know the intent of the program.

Teleport cybersecurity blog posts and tech news

Every other week we'll send a newsletter with the latest cybersecurity news and Teleport updates.

Subscribe

Enough of the buzzwords — how does this fix SSO?

Before diving into the solutions, let me define what my ideal UX would look like.

I start my work with a SINGLE sign-on to my Identity Provider, assuming I’m still employed, and I completed my passwordless login with my Hardware Token, I don’t have to tap that thing for another week*. I’m able to access all core applications and CLI tools without having to do the SSO dance again. I can access my dashboards, CI server and AWS credentials without having to see a login redirect page again.

*sudo-mode - sudo-mode is a nifty feature used by Github, or some might say ‘zero-trust gate’ that requires users to re-authenticate again for sudo-protected action; such as updating an email address or adding new public keys. This feature is a great anti-phishing measure when combined with a strong 2FA and all evaluates an action to something that is important / potentially dangerous.

To obtain SSO nirvana, we need to think outside the browser sandbox, which is always becoming more restrictive based on the advertising world abusing cookies, and provide some level of trust at the OS level.

At Teleport we think the secret lies with certificate authorities and client certificates. Certificates make it easy to encode both identity and session duration into the certificate, meaning no need for cookies of endless redirects. A client certificate can then be presented to the applications to get access, but there is a catch. The UX and tech for PKI Infrastructure isn’t great, and the client UX sucks. We hope to change it this year. If you would like to get a preview, sign up for to our newsletter, where I deliver similar security and DevOps rambles into your inbox on a bi-weekly basis.