Hey everyone, I'm Ulysse, CTO at SSOReady (https://github.com/ssoready/ssoready).
SSOReady is an open-source (MIT) service that lets you implement SAML single sign-on without ever touching SAML yourself. You just need to implement two API endpoints: one to initiate SAML logins and another to receive incoming SAML messages. And then you're pretty much done.
Here's me setting up SAML single sign-on in under a minute: (https://www.youtube.com/watch?v=_HVtFkW8xCI).
You can use our service with whatever tech stack or programming language you prefer.
Earlier in my career, I worked on SAML authentication at Segment. I've been pretty obsessed with SAML since then. In the depths of the COVID pandemic, I even wrote an implementation of SAML in Go to entertain myself (https://github.com/ucarion/saml).
Over the years, I've gotten really itchy to build better SAML tooling. There just aren't a lot of great options out there. Almost no one seems interested in making SAML easy for developers. Almost no one seems interested in writing clear documentation.
We're hoping to change that with SSOReady. We've open-sourced our codebase on an MIT license. You can do pretty much whatever you want with the code. Fork us. Self-host us.
We've also made the product entirely free.
Why free and open source? We're focused solitarily on becoming developers' first choice for SAML SSO. If it makes developers' lives easier, it works for us. We expect to monetize in the future by building extra features that serve large companies with complex needs. We don't see any point to being secretive or squeezing dollars out of small companies.
I'd be thrilled if you gave the product a try, and I'd be really grateful for any feedback on your experience.
If you have any questions or concerns, my cofounder Ned and I will stay active on this thread throughout the day. You can also reach us directly at founders@ssoready.com. (We really mean this! We want to hear from you!)
If you had SAML plus SCIM (or even just a small subset of SCIM) I think it could be a no-brainer. Other services that offer it are closed-source and absurdly expensive, and DIY is a big pain.
During the YC application process, was this enough to be accepted? I wonder how much emphasis they put in the business model in order to fund you. I wish you success!
Yes, absolutely. The code you'll write will cover all IDPs. The variation from one IDP to another gets addressed in the configuration settings for each of your customers.
For example, I put some documentation together specifically for Entra not too long ago here: https://ssoready.com/docs/idp-configuration/guides-for-commo...
Does that get you what you need?
Part of the reason we're comfortable with a generous free offering is the basic truth that helping SaaS companies support SAML logins ... just isn't an enormous market. We need to make money on other products anyway.
*Monetizing extra features* pertains to the SAML product that we offer now, but we'll also roll out other products.
The long-term ambition here is that we build a company resembling Auth0, but open source and more developer-friendly.
That said, the pricing worries me a bit. This is a tool we'd have to build on top of. Which means that if it disappears later because you went out of business (or just changed your pricing in some way that hosed us), we'd have a whole big, unexpected engineering project to rewrite our SSO.
And given that you're giving a hosted product away for free, it seems pretty likely that you will either eventually go out of business or change your pricing.
I know it sounds silly, but as someone who'll probably have to add SSO to my current project in the next 6-12 months, I'd be a lot more comfortable betting on you if you had a sustainable-sounding paid tier other than "free for now" and "idk email us." It'd certainly make it easier to pitch to the rest of my team. :)
Honestly IETF did a pretty good job with SCIM itself. It's not wacky in the way SAML is at all. In my experience the hardest part about integrating SCIM is setting up all the IDP-specific configuration around it. Like with SAML, it's a situation where Okta, Microsoft, OneLogin all have totally different terms for the exact same thing.
One thing I'm pretty excited about is that our SCIM support will also include a button where you can generate a setup link that you give to your customer. From that setup link they can self-serve configure their SAML+SCIM configuration.
We have that working for SAML right now, and it's nice because it means you don't need to write IDP-specific documentation walking customers through each product's weird terminology and quirky UI.
We wrote our own IdP back in the day. It was a cool project, Single Sign On, Single Sign OUT, User provisioning, just all sorts of stuff.
And it worked! It's amazing when it works, it's just like magic. You giggle when it works.
We did all sorts of integrations. To random Service Providers, integrating with other IdPs, etc. Some were really cool. Great functionality.
But I simply float this one caveat.
It was never "painless". Ever. It was always pulling teeth.
The dark truth is you can have the best IdP in the world, but everyone on the other side of the conversation is a black box. You get a lot of payloads simply shipped into the void, never to be seen again, consumed for some unknown reason.
Add to that the very often the people you're integrating with have no concept of SAML, its workflows, its payloads, etc., much less the capabilities of their own stack in regards to SAML. So you get to train them (and learn about their system) at the same time.
We never had real problems with signing and formatting and such that folks worry about. It was mostly just diagnosing black boxes more than anything, the endless black hole of cert management, etc.
So, good luck! I hope it works for you! It's a neat space to play.
You have a python SDK, but something like https://github.com/SAML-Toolkits is popular, well maintained, and fully featured. Why use yours?
I may not successfully convince you of the commercial logic here, but we are making a calculated bet that a generous free offering serves our long-term interests.
We're betting that this product will establish our credibility with developers and result in efficient distribution in the future. It's a pretty common commercial open source playbook not to monetize in the early days.
Thankfully, some subset of venture capitalists will happily underwrite companies with popular commercial open source products.
Please bear in mind that we're an early stage company. We will build more depth into the existing product, and we'll offer new products over time. We will charge for those new features / new products. It may take years to earn meaningful revenue, let alone generate cash flow, and we're fine with that.
We have automatic volume discounts for pay-as-you-go users, and even lower prices on annual plans or custom contracts. We also have free credits for early-stage companies. Feel free to send me a note if you’d like to chat: mg@workos.com
Today hundreds of companies use WorkOS, including a ton of startups you probably know: https://workos.com/startups
Take any language's biggest SAML implementation, and it's the same story of a library with some epic README covering dozens of public methods you may or may not need to use. People can't make heads or tails of this stuff.
Clarity and simplicity are the precursors to security. I'm pretty obsessed with making SAML clear and simple for folks.
I think you'll have better luck on the consulting side with this idea than the product side. There are so many SAML implementations running the gamut from plug and play like Auth0 to DIY toolboxes that I don't think "simpler" is a good enough value add here.
Right, but what has become common, if successful at cornering market share, is then changing the license to something open-source-ish and charging money for what used to be free. Sometimes a lot of money.
Many swore they'd never do it. Many probably even meant it at first.
So, it's a concern for sure.
I even wrote a blog post about this years ago that was popular on Hacker News: https://cranberryblog.substack.com/p/a-simple-argument-for-i...
Sometimes you have to defy best practices :)
> And it worked! It's amazing when it works, it's just like magic. You giggle when it works.
And then this
> It was never "painless". Ever. It was always pulling teeth.
Even with a caveat in between, is misleading. I get you’re probably trying to generate revenue, and more power to you. I’d re-work that phrasing next time.
This is true of a great many protocols, unfortunately. I've seen this with IPSec, HL7v2, … CSV.
IPSec was perhaps the most … scarring. Always sort of feeling your stomach turn to acid as you wonder to yourself "will we be able to integrate with the other end?" when you're trying to work with "network engineers" who cannot establish a TCP connection to test if the VPN tunnel is alive. And yeah, it's learn their system as fast as humanly possible to then determine if their setup is correct, and to hunt where the inevitable integration problems lie. (…in the firewall. It was always a firewall, somewhere.) Why other systems feel the need to take the standard terms and reinvent new words for them is beyond me to this day. "Enterprise" junk is particularly guilty of it. Most of the learning is just building a mental Rosetta stone of what does the other end's "appliance" call this term or that term.
Making authentication and SSO more painless will actually make the world a better place -- apps will become more secure, people will be less frustrated when they use them, etc., and people like me will have less stress in their lives.
Incidentally we just shipped something for this. Rather than having to make a 204-page PDF, you can go into SSOReady, generate a setup URL, and give it to customers. Customers can visit that URL and they get a self-serve UI for configuring their SAML connection to your product.
https://ssoready.com/docs/idp-configuration/enabling-self-se...
This sounds like a good problem to solve with LLMs, and honestly I'm a bit surprised to hear that nobody cared about data being of poor quality. Care to elaborate a little bit?
Also an option, when choosing what to use right at the startt, is being careful about using an open source solution from a for-profit startup, and evaluating all your other options, taking into account that it may not remain open source, and if it doesn't, what place it has in your business, how hard it would be to switch then, etc.
Our positioning (e.g. principal use cases, target verticals, target persona) and timing were totally wrong. We tried to run top-down sales against relatively important data (e.g. sales forecasts). People often expressed an attitudinal interest in the product, but it was very hard to motivate people actually to use the product seriously. Category creation and behavior change are really hard.
If I were trying to sell an LLM data cleaning product now, I'd focus on more technical buyers, someone more like a data engineer than a strong spreadsheet worker. And I'd try to drive bottoms-up, low ACV adoption first.
Doing the post-mortem justice would probably require a long blog post.
Side thought: If this takes off as a popular quality implementation, an additional effect might might be that it's easier for vendors of other services to integrate with users of your software. Maybe there's some way you can profit from that savings or reduced sales friction. (I've had to implement several F500 SSO integrations from scratch, because they were doing bespoke/custom things, and even "SAML" doesn't necessarily interoperate, but software like yours might out of the box.)
Question: For the free hosted SSO, how well are you going to be able to secure that, so that your customers aren't compromised through you?
Question: Will the free tier SSO have uptime guarantees, since it'll be a single point of failure for all your customers? For startups that decide they'd like it hosted for them, but need an SLA, do you expect to be able to provide that at a price doable by startups? (Will a cloud provider pick up those customers using your software?)
Not sure if this is still true, but for a while Okta would not allow you to use OIDC for SSO in an Okta integration that used SCIM — you had to use SAML for SSO. We basically worked around this by having two separate Okta integrations — one for SSO and one for SCIM. It was always a pain to explain this to our customer’s IT departments, but no one ever balked at it, so we never had to implement SAML.
Yeah, this is super important. No short answer here, it's just about doing the work and getting it right.
We're working with Oneleet for our SOC2 stuff (which we all know is largely theater) but also pretty thorough pentesting. I can email you their findings.
The reality is we're one of those companies that need to get this stuff right.
> Question: Will the free tier SSO have uptime guarantees, since it'll be a single point of failure for all your customers? For startups that decide they'd like it hosted for them, but need an SLA, do you expect to be able to provide that at a price doable by startups?
Our plan is to work out agreements on a case-by-case basis. It'd depend on exactly what you need. We take guarantees pretty seriously, so we're careful about what we promise.
We're not a services business. We don't want to make money off of "premium support". There is a modest price tag if you want an SLA.
> (Will a cloud provider pick up those customers using your software?)
Would you mind rephrasing?
We prefer our approach for basically two reasons:
1. BoxyHQ wants you to do SAML-over-OAuth. We support this -- especially for NextAuth compatibility. But we don't think it's always helpful.
2. We think our service is easier to use. We most commonly hear complaints from users/customers about complexity, so we try really hard to make SAML obvious and simple. Ultimately, it's up to you whether we meet that bar.
https://en.wikipedia.org/wiki/Elasticsearch#Licensing_change...
[1]: https://sso.tax/
One of my favourites was the time I was trying to figure out a SAML integration with a client, and before the person on the client's "SSO team" could figure it out, I installed a demo of their SSO solution, integrated with my own dev AD, and found the checkbox.
Yay enterprise! The Q in enterprise is for quality.
One of the biggest challenges is our users tended to need to pull in a different department, that actually owned the SSO system. They had little incentive to hustle to get things to work, so there’s tickets would often drag on for ages.
We’d loom bad because we’d need certain information from our customer.
I don't see how a proprietary authentication proxy atop a partial implementation of a SAML service provider addresses problems with enterprise SSO, which I'll wholeheartedly agree is just too goddamn hard.
The open source community doesn't need yet another open core project, for that matter.
0: https://lists.oasis-open.org/archives/security-services/2023...
Seems reasonably easy to use and a good platform to build a SaaS
net::ERR_CERT_DATE_INVALID
Subject: lists.oasis-open.org
Issuer: Sectigo RSA Domain Validation Secure Server CA
Expires on: Jul 8, 2024
Current date: Jul 31, 2024
502 ERROR The request could not be satisfied. CloudFront wasn't able to connect to the origin. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner. If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation. Generated by cloudfront (CloudFront)
cf. http://www.site-shot.com/Lu-cUE7TEe-S-wJCrBEAAg or https://archive.is/wip/FhNfD
Otherwise the project looks really well done and by nice people.
SOC2 is only theatre if you (a) you already have good practice, and (b) can demonstrate that you have good practice. If your practice isn't good enough (like the whole notion of security controls is a foreign concept), and sure there's a lot of boilerplate to work through -- but the whole point of a SOC2 Type 2 report is that you only have to demonstrate once to the auditor, rather than to each customer each time.
Having to get internal security sign-off for a non-audited SaaS vendor -- really, life's just too short for that most of the time, and if there's choice of two more or less equivalent providers we go with the certified one every time.
SPF, DMARC, DKIM is setup correctly. Domain name A/AAA/TXT/MX records all setup and propagated throughout the world. Mail server tested with external tools like mail-tester.com
…
But there is a whole new world of “other mail servers” now. Some mail servers are okay. Delivery works fine. Some mail servers have odd policies and implement strict block lists and maintain their own rep of each domain/sender.
How do you expect people to bootstrap an infra SaaS? I just don’t see how you can seriously attempt something like an Auth0 competitor startup without any money. I mean it’s nice to not take VC money but you are going to be broke for a long long time - and you still have the same failure rate as with VC.
So you need to be super masochistic to work for nothing for years with a 99% of everything will evaporate at any point - and at the same time somehow convince companies to build on your stack - not only build on it but make it the gatekeeper and front door of everything. I can tell you that you will have an extremely hard time to get any customers for this, regardless of how great the tech is.
Maybe you don’t need it at seed stage - but unless you are fantastically rich already you need some investment to get beyond seed stage IMHO.
One thing I didn’t see mention of is group membership. Is this / will this be part of the core offering? Being able to map IDP group membership to permissions within your SaaS is powerful, and in my experience highly desired by clients.
I am building a SaaS application and wants to allow customers from different companies , each with their on IdP to be able to SSO into my application , which is a multi-tenant SaaS offering.
Presumably ilrwbwrkhv is thinking of the fate of ElasticSearch, MongoDB, Redis, CockroachDB, Confluent, TimescaleDB, Terraform, HashiCorp Vault, Docker Desktop and suchlike.
The VCs want a return for all the money they've invested, and it's difficult to monetise a free product.
One way to avoid letting down your community is to have your product be a closed-source paid product from day 1. Another is to get the backing of a huge multinational with endless ad revenue. Another is to run a super lean one-man operation, or get a day job and make free software your hobby. Another is to teeter on the edge of bankruptcy and hope one of your users just acquires your entire company.
Or you can just disappoint your community - SAML's only used by faceless megacorporations anyway, it's not like you'd be letting down real people.
None of these are great options IMHO - but that's why I don't have a VC-funded infrastructure startup myself :)
One of my favorite bad examples of this is Supabase. They played into the whole open source Firebase bandwagon and while their code is available, the ethos of open source is completely lost, so much so that even now local development and self hosting is a pain.
In terms of good examples, Andrew Sherman who does Drizzle ORM is a good example of this. Here is one of his tweets talking about not taking VC money: https://x.com/andrii_sherman/status/1775954643022971044
> I quit my job to start working on Drizzle full-time. It's still not VC-backed(and will never be!), and we are still doing everything thanks to our great sponsors and our first successful B2B integrations.
So it can work but honestly the best open source projects start off when you are getting paid a salary and you work on the project because you are passionate and love working on it.
https://ssoready.com/docs/api-reference/saml/redeem-saml-acc...
So if you're familiar with Okta's parlance, both "Attribute Statements" and "Group Attribute Statements" are returned to you in `attributes`.
[1]: https://ssoready.com/docs/api-reference/saml/redeem-saml-acc...
So, some questions:
1. First, do workplaces or SaaS app providers not need Android or iOS app support for in-house or client / customer facing apps?
Swift and Kotlin SDKs seem conspicuous by their absence.
2. Second, what about OIDC?
I'd argue the majority of business and business employees do not need "SSO", the majority of benefits they think they'd get are met by OIDC ("Sign in with..." buttons) for users with the firm's controlled email address @ firm domain as the login username. A plurality of big firms seem covered just by "Sign in with Microsoft", and "Sign in with Google" to pick up startups or individuals, followed by GitHub for devs or Apple for retail wallet share.
In our shoes, we'd far rather support clients through OIDC than SSO.
3. Third, Google has this covered if a startup bets on it, while Microsoft and AWS are a confusing melange of some 20 years of backwards compatibility, making bridging from devices into their Microsoft Entra or AWS IAM worlds hard to understand even if fully supported.
At the same time, many businesses with real budgets are "required" by senior management to stay within those ecosystems.
This calls for a frictionless experience and abstraction on top that uses the native mechanisms under the hood so the rest of the CSP ecosystem understands the users' identities, roles, and attributes, enabling CSP native security to protect the CSPs other offerings.
Have you considered being the experience on top of AWS's Cognito for example, letting you drive it and then IAM RBAC for their various systems, effectively offloading "securing" of the mechanisms to the CSP, while handling the complexity that only those who've learned those mechanisms can master?
For reasons, we want to bet our actual under-the-hood security controls on the CSP's security controls. For example, of all participants, they have the most to lose from a controls failure. And some, like AWS, bring a level of discipline to security controls nobody else seems willing to afford, such as through their "formal reasoning" or "provable security" work:
https://aws.amazon.com/security/provable-security/resources/
Concept:
Ever since you've launched, it's seemed to me that WorkOS might be the best envisioned suite to be the layer on top of CSP native security engines and security controls (directories, secrets, IAM, RBAC/ABAC, row level or cell level security, etc.).
We only have a few dozen employees, and as a startup are very sensitive to recurring costs, but are still heavily regulated. If thinking in developer-hours, we would cheerfully pay up front a quarter or two's worth of dev time (depending on in which market you measure value of dev time) for OOTB "integration" of such a layer on top of the native CSP mechanisms. This could include some nominal and proportional amount relative to, say, the recurring cost of Microsoft Teams (e.g., less than $4 a month) at the consumer end or relative to the delta between M365 and M365 E3/E5 Advanced Security on the enterprise end (if you look at what's included for +$10/month, you can see most per-seat security tools are overpriced:
https://www.microsoft.com/en-us/microsoft-365/enterprise-mob...
Given the amount of "stuff" already paid for in one of those plans, that's a lot of "stuff" you wouldn't have to do. Arguably, if you're the frictionless UI and configurator rather than providing the controls themselves, you're out of the "critical path" entirely, meaning easier contracts with businesses where the regulator wants regulated entities to negotiate for financial indemnification if the vendor fails.
TL;DR:
This isn't what you do, and probably shouldn't be, but maybe someone else will read this concept and think they should. We're not the only ones who would buy it!
Longer comment elsewhere in thread.
Will read through this again and think more carefully about it later today.
Arguably, OAUTH2 + OIDC does this. Firms like Atlassian have understood this:
At the time we looked at various open source implementations, and ended up using OneLogin's PHP library. We wanted a headless library, so we could store the SAML metadata in our main DB and implement the public endpoints on top of it.
It did take a few days of googling and trying, but it wasn't really that complicated. Our core implementation adds up to just some 500 lines of PHP, most which is just glue code to fetch metadata from the db, put it in the format the library expects, and then do the basic thing of sending the user to the IdP, getting the response back, checking it, and mapping a couple of attribute names.
The advantage of this approach is that we were able to made it self service for our users. User logs in as admin, goes to "SAML settings", inputs their metadata, clicks a button to test, and if it's good, clicks another to activate. We did get a few support requests from people who didn't know their own systems very well, but otherwise it's working smoothly.
> 1. Do workplaces or SaaS app providers not need Android or iOS app support
All identity providers are 3rd-party systems that authenticate a user via a web experience. They don’t have a direct way to submit credentials. e.g. In Okta SAML auth, your app redirects the user to a hosted Okta UI which verifies their identity and then redirects back to your app.
WorkOS supports this on mobile via webviews and custom URL schemes, so the redirect back can be `yourapp://callback` etc. This is simple enough to build that developers haven’t asked us for a custom Swift/Kotlin SDK. However, it’s still a good point you raise and we should add better docs. Will make a note.
> 2. What about OIDC?
WorkOS supports SSO via OIDC including Okta OIDC. In practice we have found OIDC much less common than SAML despite it being an improved protocol with fewer sharp edges. I’m not sure why this is other than legacy enterprise IT vendors being slow to change. Perhaps OIDC is 2x better but not 10x better.
There are lots of cool ideas to improve the world of SAML+SCIM including FastFed [1] but unfortunately they are stuck in a proposal/prototype state and have not yet overcome the coordination headwind of multiple vendors simultaneously launching support. I hope it happens someday!
> 3. Have you considered being the experience on top of AWS's Cognito…
It’s an interesting idea to build a better front-end to Cognito and similar platforms so developers can leverage underlying CSPs. In a sense this is what we’ve done with WorkOS SSO [2], which abstracts all the hairy bits of SAML behind a simple OAuth API. We’ve done the same thing with SCIM [3] by integrating all the various directory systems into a single API with modern semantics and predictable responses. WorkOS is like “Stripe for enterprise features.”
What I’ve personally seen is the innovation cycle for Cognito is glacially slow. As an example, at AWS Re:Invent last year there were zero sessions on Cognito and I couldn’t find a single PM to talk about the product. Perhaps Amazon will eventually ship something but today Cognito is clearly not a priority for them.
So instead we built WorkOS. We started with SSO and SCIM and then launched the Admin Portal [4] which makes IT configuration — otherwise a headache inducing process — an easy self-serve wizard. This design has been successful enough that we’ve attracted competition (and even some open source clones. ;)) Overall though I am glad to see more people working to improve the lives of developers building enterprise SaaS.
In the last couple years, WorkOS have been expanding our product into other areas of the IAM stack. Last year we launched a fully-managed identity service called AuthKit [5] which includes powerful features like session management, impersonation, and RBAC. AuthKit is an alternative to Auth0 but it’s free up to 1,000,000 users.
A few months ago WorkOS acquired Warrant (YC S21) [6, 7] which provides a fine-grained authorization (FGA) service inspired by Google Zanzibar. This enables developers to model even the most complex data authorization with a single runtime. Warrant is open source and is an alternative to AWS Cedar, SpiceDB, and Oso, and other. But it has some differences, such as the “edge agent” which allows permission checks to be evaluated locally within your app. Super fast, no HTTP requests required. [8]
We also love open source. WorkOS builds Radix UI [9] which has something like 30M monthly downloads and powers the design systems for Linear, Vercel, and others. I even considered starting WorkOS as an open source platform. But what we heard from developers was that code was only part of the solution. They wanted a service that included ongoing support and dependable uptime. They want to just pay and make the “enterprise problem” go away. That’s what WorkOS does.
We’ve found smaller startups are also fine to pay for features like SAML and SCIM because they enable selling upmarket and unlocking enterprise revenue. Often startups will just pass on the WorkOS cost in their own enterprise contracts. Our pricing is usage-based, transparent, and easy to understand. And it doesn’t require clicking “Contact Us” and negotiating with a sales rep. [10]
Building a layer on top of other IAM/CSP systems initially sounds appealing, but ultimately I don’t believe it will let us achieve the goal of providing the best possible developer experience with the most robust features to users. To do this right we need to invest deeply in the technology primitives. We’ve raised $100m and today have hundreds of customers and millions in revenue so we’re well on track to solve this problem for everyone.
Hope this adds more color. Happy to answer other questions here or via email anytime. I’m mg@workos.com
[1] https://openid.net/wg/fastfed/
[2] https://workos.com/single-sign-on
[3] https://workos.com/directory-sync
[4] https://workos.com/admin-portal
[7] https://workos.com/blog/workos-acquires-warrant
I have been working on this for a few years at github.com/authgear, and last few weeks were busy rolling out SAML support for a few Enterprise customers want it by Sep…
Magically feels connected here :)