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-check 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.
