The “human cost” of SSO is definitely the hardest part.
At WorkOS we solved this by shipping the whole config workflow in the form of an admin portal. It checks things like SAML certificate, signatures/assertions, attribute mapping, etc. and a zillion other edge cases across dozens of identity systems.
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
WorkOS is incredible, and we've admired it from afar since launch. We'd like to use it, but aren't sure about the roadmap or applicability for SaaS “app” provider needs that otherwise seem like a perfect match.
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.
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:
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:
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!
> 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
It's a cedar related issue. I like to know every check that was run for a policy and the result. Cedar will only provide the name of the policy that granted/denied.
Wow, this is quite a surprise! I've seen products like this, but nothing with the kind of free tier that is being offered here (for my exact use-case!). That's pretty awesome. I'll definitely give this a try!
I do have some reservations about maybe walking into a lock-in situation, but it looks like there are enough outs to make the easy way worth being the first way. Thanks for the link!
At KPAO the main thing to know is 1) on departure turn 10 degrees right after clearing runway for noise, and 2) they will often extend the pattern for more space when it gets busy. On the departure/upwind leg, they may extend you to the train bridge or the auto bridge (Dumbarton bridge) before you turn crosswind. On your downwind leg, they may extend you to the amphitheatre, which is the white tent looking thing near Google. This actually runs into KNUQ (Moffet) airspace but the controllers coordinate this so it's fine. And don't extend unless they tell you!
For KSQL, new pilots mostly get tripped upon the departure procedures. You can fly the Hillsdale departure, Oracle departure, Coyote Hills departure, or Woodside departure. KSQL is a short hop from KSFO and under their jet approach, so the procedures are intended to create more predictable incoming/outgoing traffic. Annoyingly, these departures are not charted and instead published as part of the "voluntary noise abatement procedures" by the airport. You can read them here (PDF) https://www.smcgov.org/media/57331
Both are great little GA airports. I learned to fly with West Valley Flying Club and wholeheartedly recommend them. Friendly pilots and a supportive community. If you have questions, just pop into their office and you're likely to find someone you can ask (and get stuck talking about airplanes for an hour :)).
For PAO specifically, also helpful to know where KGO (trio of radio antennas alongside bridges), the Dish / Stanford, Sunken Ship (what it sounds like), the Birdhouse (round structure between Amphitheater and PAO), Amphitheater (as well explained in top comment), 101, and train/auto bridges which often get used as visual landmarks.
For SQL, I can’t really remember too many landmarks that get used often other than Cement Plant (cement plant on the bay slightly past south side of the field) and AT&T (big grey building).
we’ve had lots of folks migrate from Cognito to WorkOS. Lots of more features, modern API, and better extensibility.
More here: https://workos.com/docs/migrate/aws-cognito