Like many others we couldn’t justify the Enterprise-plan for every SaaS tool to simply get access to SSO and SCIM/SAML APIs. For Notion alone the cost would have nearly doubled to $14 per user per month. That’s insane! Mostly unknown to people, SSO Tax also limits access to APIs that are used for managing user access (SCIM/SAML).

This has proven to be an incredibly annoying roadblock that prevented me from doing anything useful with our user data:
- You want to download the current list of users and their permissions? Forget about it!
- You want to centrally assign user roles and permissions? Good luck with that!
- You want to delete user accounts immediately? Yeah right, like that's ever gonna happen!

It literally cost me hours to update our access matrix at the end of every quarter for our access reviews and manually assigning user accounts and permissions.

I figured, there must be a better way than praying to the SaaS gods to miraculously make the SSO Tax disappear (and open up SCIM/SAML along the way). That’s why I sat down a few weeks ago and started building OpenOwl (https://github.com/AccessOwl/open_owl). It allows me to just plug in my user credentials and automatically download user lists, including permissions from SaaS tools.

Granted, OpenOwl is still a work in progress, and it's not perfect. At the moment it's limited to non-SSO login flows and covers only 7 SaaS vendors. My favorite part is that you can configure integrations as “recipes”. The goal was for anybody to be able to add new integrations (IT managers and developers alike). Therefore you ideally don’t even have to write any new code, just tell OpenOwl how the new SaaS vendor works.

What do you think? Have you dealt with manually maintaining a list of users and their permissions? Could this approach get us closer to overcoming parts of the SSO Tax?

As a former CTO at a VC-backed and security-conscious company, I've faced the tough choice of skipping costly enterprise upgrades, even when SSO was crucial.

Take a look at Notion: to access SSO, they casually double their standard pricing.

Imagine buying a Tesla and being charged extra to unlock full braking power. That's what SSO Tax is - vendors exploiting a built-in feature, essential for security, to extract excessive fees.

So, why initiate a new project?

Rob Chahin's work on sso.tax initially highlighted this issue. However, the site's updates dwindled, and data became outdated. Despite offering assistance, I received no response, leading to the creation of https://ssotax.org. While there has been short spike of activity post-fork, it already stopped again. That’s what we’ve seen often in the last few years. Instead, I want to give the topic the attention it deserves.

In addition of integrating all pending PRs and enriching the data, I’ve introduced a new feature: "Friends of SSO". We should not only call out unfair practices but also praise vendors who are committed to security!

Furthermore, I’d love to raise awareness about vendor practices by utilizing Twitter and Linkedin to publicly praise or critique them. The goal is to get attention for the topic, ideally sparking conversation with the vendors involved.

What are your thoughts on getting rid of the SSO Tax? Excited to hear your ideas!

Most of us use SaaS tools for work day-in and day-out. How do we get access to those tools? For the most part, through a colleague or IT admin who creates all accounts and sets permissions manually.

Here’s what it usually looks like for the unfortunate admin: (1) receive a request for a new tool via email, Slack, JIRA or face-to-face. Since you are busy with something else, you write a todo for later; (2) you log in to the tool and realize that the permission that was requested is way too high so you check in with the requestor’s manager; (3) you finally set up the account and document user, tool and permission in a Gsheet/Notion/Airtable.

This quickly becomes a 30m task for a simple access request! This is still the best practice for most people and it sadly also was for us. We were both founders before and experienced the same tedious process in different flavors at our own startups and other companies.

At some point we migrated to Okta and partially automated our provisioning and deprovisioning (permissioning, however, stayed painfully manual). Why only partially automated? Because Okta utilizes the SCIM API which was either not available in our tool stack or required an expensive upgrade to enterprise-subscription (thanks to the “sso tax”: https://news.ycombinator.com/item?id=31175300). And yet, we still missed simple things such as approval steps, a straightforward way to request access, and access reviews.

We talked to hundreds of organizations and saw the same manual processes and self-built scripts everywhere. The pain often starts at growing companies with around 50 employees. At this stage the CTO usually gets fed up with manually (de)provisioning and documenting it in a Gsheet. Another widespread cause of headache are IT security certifications (e.g. SOC2, ISO27001,...), requiring to know which employee has access to what tool, regular access reviews, and timely offboardings.

It seemed crazy that in a world where SaaS has become the norm, there was no great way to manage something as seemingly “trivial”, but also as critical, as user accounts. The core issues are, as always, missing integrations. Despite SCIM being the standard for over a decade, not all applications are utilizing it. Worse, many vendors lock it up in their enterprise plan.

This brought us to our core design principle: AccessOwl has to work with every tool, no matter what integrations are available. We generalize all the available ways of integrations in a single, simple interface. We take care of all the grunt work needed to coax each SaaS tool into doing the right thing. Whether it’s calling public APIs or resorting to Plaid-style automations as a last resort. Our first iteration was a simple workflow in Slack (Request -> Approve -> Manual provision). It covered all access documentation and solved back-and-forth communication between stakeholders. Since then, we have been adding more and more integrations to SaaS tools to directly (de)provision without the use of SCIM APIs. Taking a similar approach to provisioning as “Plaid” did in banking. We’re already covering 100+ tools and counting.

So what does a typical workflow look like?!

Step 1: Request an access, onboarding or offboarding. For this we piggy-back on whatever messaging tool is used in your org (we are starting with Slack, Teams will follow). It’s as simple as clicking a button to get your request started (no more manual JIRA tickets!) and always gets forwarded to the right stakeholders.

Step 2: Provisioning and permissioning. In the most basic workflow the tool owner receives the approved request with all the information to manually provision the account. If and when you arrive at the point where manual provisioning becomes a pain, you can let us automate it for you. The requestor will automatically get process updates and the access will be audit-ready logged in the background.

Prices start at $2.5 per employee per month and we charge a fixed premium for the automation of (de)provisioning based on the total number of employees.

We are excited for the opportunity to share AccessOwl with you! We would be more than excited to hear your thoughts and feedback and your own experiences with SaaS access management!

TL;DR: We’ve launched a free version of our Shadow IT scanner to identify which SaaS apps are used in your company, who uses them, and if they have high-risk OAuth scopes.

Philip and I went through YC with AccessOwl in 2022. We started the company because, in our previous roles, we struggled to track all the SaaS apps, users, and granted OAuth scopes.
The Shadow IT scanner started as a small feature within AccessOwl, which manages SaaS vendors and user accounts centrally. But a standalone scanner would have made our lives so much easier in our previous roles. So, we thought, why not release it?

And here it is: a free, standalone Shadow IT scanner!

Hope you find it useful :) The Shadow IT scan helps with:

1. Offboarding: Employees often don’t report all the apps they sign up for, making it tough to track and secure these accounts when they leave, especially with the common SSO tax.

2. Security: OAuth scopes are quickly granted but rarely reviewed or removed, leading to organizations unknowingly spreading their data.

3. Compliance: Auditors need a list of SaaS vendors, which is hard to compile when employees sign up for tools independently.

Any surprises in your scan? What features would you like to see in the next version?
Looking forward to your feedback!

FAQ

What’s Shadow IT?
Unauthorized SaaS apps within an organization not centrally managed, posing security and compliance risks.

How does it work?
Our tool connects to your Google Workspace or M365 instance, identifies OAuth tokens granted, and maps them to known SaaS tools. Note: In this v1 version, it only detects apps using the “Sign in with Google/Microsoft” button.

Who is this for?
Typically IT and InfoSec teams, but in smaller companies, it may fall under the CTO.

Is it safe to use?
Yes, reading OAuth tokens is standard for SaaS management tools. Data extraction only occurs when you initiate a scan. AccessOwl is SOC 2 Type II audited and GDPR compliant.

Every company actively decides at some point in time how employees shall login to SaaS vendors. The typical answer for early stage companies is Google SSO, whereas later stage companies tend to switch to Okta SSO.

In the early SSO days Okta was the best option to get MFA and granular controls. However, nowadays Google is offering 2FA as well. It’s also often the default option with many SaaS vendors and therefore neither requires manually setting up SSO nor requires an enterprise-subscription (see [sso.tax](http://sso.tax) for reference).

Therefore, why do you believe people should still use Okta?

- Is the biggest reason to use Okta their SCIM-Provisioning, RBAC etc.?

- Are there any limitations in Google Workspace that only Okta solves?

- Or for the Google folks out there: What’s the reason you are sticking with Google SSO?

I am curious what you think about open sourcing a little tool I wrote. But before, let me give you some background: I was building two fintech companies before and we had several audits per year. As the financial industry is regulated, it wasn’t a “voluntary” audit like SOC2, ISO27001 or HIPAA. Hard findings posed the risk of not being able to do business anymore.

One of the high priority auditor items was having a proper access management process to ensure that user accounts of former employees are revoked and existing users follow least-privilege principle. Even when we used Okta, in many cases we couldn’t get the data in an automated way. Either tools were not covered or behind a (way too high) paywall. Thanks SSO Tax

Back then I wrote a little tool to download user lists with their permissions from our major SaaS tools. That helped us a lot to verify user lists. Later I even added functionality for some tools to create and delete user accounts as this was another pain we got.

However, I am thinking about making the tool open source with support for a bunch of applications that can be easily extended.

Would such a tool be useful for you? Are there any other information besides users and permissions you would find important? Would you see yourself contributing to a open source project like that?

I know every company I've worked at that didn't have SSO had problems offboarding people because each group (eg, Finance, Product, Engineering, etc.) purchased their own set of SaaS services and there was no central place for IT to manage access.

The downside is cost. Some companies charge 100%+ the base price for sso (https://sso.tax/).

[0] https://sso.tax