EN
Back to the archive

The archive · Product Ideas · Product decision · 2023

AccessOwl open-sources OpenOwl to pull your own SaaS user data without the SSO tax

OpenOwl logs into SaaS like a user and calls its internal API to export user lists and permissions — open-sourced as shareable YAML recipes.

AccessOwl

The ideaBeat the SSO tax with the app's own UI path: sign in like an admin via Playwright, call the internal API the web UI uses, export user lists via YAML recipes.incremental

What it had to solve

Knowing who has access to your SaaS tools is often guesswork, and SCIM/SAML — the standard way to read and manage that — are frequently locked behind enterprise subscriptions. AccessOwl, a startup automating SaaS account provisioning, wanted IT Ops, InfoSec and compliance teams to read user lists and permissions from any tool without needing a public API or a developer.

How it works

OpenOwl began with a frustration AccessOwl's founders had felt building SaaS provisioning tooling: SCIM and SAML, the standards that let organisations see and control who uses their SaaS, are often gated behind enterprise subscriptions. For a mid-size company, simply knowing which accounts exist in which tools — for audits, orphaned-account checks or access reviews — can mean guesswork or paying for a tier it does not need.

The tool's design sidesteps the gate rather than fighting it. OpenOwl signs in like a regular administrator using username and password automation via Playwright, then calls the same internal API the web application's own UI calls to fetch the user list and permissions. Because modern single-page apps are full of such internal APIs, most tools can be supported this way — and each vendor's details are encoded as a YAML recipe instead of custom code.

The open-source half was deliberate: AccessOwl, the commercial product for automated account provisioning, open-sourced this read-only core because the founders argued that having access to your own team's user data should be a basic right for anybody. Recipes are community-contributed through a documented eight-step flow — capture the XHR in browser devtools, trim it, note the pagination strategy — and a new integration can take just 30 minutes.

Why it lands

  • The internal API of a SaaS's own UI is the one interface every customer already has, so OpenOwl works without waiting for vendors to expose official APIs or SCIM.
  • Encoding each vendor as a YAML recipe rather than code made the long tail of integrations a community contribution problem instead of a company roadmap item.
  • A normal-user login keeps the tool inside the permissions the customer already paid for — read-only, no bypassing, no admin backdoors.
  • Open-sourcing the core gave the commercial AccessOwl product a credible stance against the 'SSO tax' and turned a complaint into something IT teams could run the same afternoon.
  • Naming the pain — 'SSO tax' — gave the project a slogan the discussion could rally around, as the launch thread showed.

What it did

The Show HN on 11 April 2023 drew 220 points and 103 comments, with the thread debating the 'SSO tax', whether SCIM should be offered in lower plans, and where the tool's purpose began and ended. The repository snapshot shows 276 stars, and the launch framed AccessOwl as the company that treats your own team's user data as a basic right — while keeping OpenOwl strictly read-only.

Case pageOpenOwl source and recipes on GitHub

What you can take

When a vendor charges for access to data you already own, the app's UI is a working API: sharing that replicated path as open code turns a pricing complaint into a tool anyone can run.

Since then

The repository stayed public with 276 stars and nine commits, recipes.yml remaining the living surface for community integrations, while the founders held the read-only line in the launch thread: automatic provisioning and deprovisioning stayed with the commercial AccessOwl product, and OpenOwl's job was transparency over user data. Commenters took the project as encouragement for SaaS vendors to stop putting SSO and SCIM in separate enterprise plans, and the discussion became part of the wider argument that identity features were being used as price segmentation rather than security.

Sources

spotted an error? The archive wants to know.

Your turn

You just read one. Describe the brief you are staring at, and see who has been given the same problem.

Free account · 3 free questions · no card

Related cases