It's not a big deal, but I find it annoying when people call something an OS when it's not an operating system. Like how xfinity has their "Entertainment Operating System" or whatever it is.

I think it's a big deal. I keep seeing things like that and getting kind of excited - "is this a new corporate-supported Linux distro? something cooler?" - and it never is. It sucks.

I agree. Words matter and have specific meanings. I'm tired of words being subverted for other purposes. Like "chemical free". So, you're telling me it contains...nothing? Or organic foods which has absolutely nothing to do with the meaning of organic from a chemistry standpoint. Conflating terms like this is purposeful misinformation with the intent to confuse and mislead (usually so you can charge more because the consumer thinks they're getting something different than what they're actually being peddled). The most charitable I could call it would be anti-consumer.

From a cursory look at WorkOS, it's not an OS. It's at best an app framework.

$WORK’s corporate values, etc are distilled into an “OS”. It’s been that way since it was a startup, but I still find calling it an “OS” weird.

I don't understand how you can say

>values, etc are distilled into an “OS”.

When its literally not an Operating System. Its an application, no? It runs in user space on top of a real Operating System

Speaking of weird ways to name something, why did you write it as $WORK? It doesn't look like it's publicly traded.

To a programmer or scripter, an uppercase $WORD starting with a dollar sign often denotes a variable. Thus, $WORK could denote any sort of work, or if you're religious, you might worship a $DIETY (but which one we don't know without asking, so it's "variable" information).

Sadly this script that depends on a supreme being will probably break in production because the correct spelling is $DEITY...

I guess supernatural dependencies are frowned upon these days anyway.

I support ${DEITY}, to cover the use case when there isn't one.

That's why I always put both $DEITY and $DIETY in my .bashrc file.

And what do you think an operating system is?

It doesn't need to run on hardware, as most Linux-based OSes run on hypervisors. It doesn't need to have multitasking, since DOS is clearly an OS. I would say it's just something that runs apps.

> It doesn't need to run on hardware, as most Linux-based OSes run on hypervisors.

Virtualization hypervisors typically emulate hardware. They provide a "virtual machine." It may not be real hardware, but for most purposes the function and appearance is the same from within.

You're not the only one. It's blatant false advertising and downplays the complexity of an actual OS.

Another example is monday.com claiming to be a "work OS"

Imagine you are a customer looking for an authentication solution to help you integrate with customer enterprise systems.

Were you going to search for work OS? No you’re going to pick from one of the words above.

I think inflating a product by obscuring it behind grandiose facades is a rookie marketing mistake.

Unless your apple and need a name for a new Color or something.

Sure Comcast's "X1 Entertainment Operating System" is technically just a suite of applications that run on top of an actual OS, but at least it comprises everything an end user will interact with. It's much closer to an OS than WorkOS, that's for sure.

That's arguably not too different from Android.

That's a great point, actually.

For bonus points, https://en.wikipedia.org/wiki/Workplace_OS was a thing that was an OS - when I first saw the title I thought of that first.

Yeah, it should be part of their slogan, if even at all. But „like a OS for X“ to explain is fine.

i can't count the number of products i've worked on or adjacent to that have gained some traction, started to scale... and hit a brick wall when wanting to access the enterprise market. far too often, these projects end up stopping most core feature work to add hacky versions of whatever's required to close that enterprise sales gap. they slow velocity while incurring tech debt.

a SaaS product that offers some developer-friendly ways to drop these capabilities into your system could be a huge win for companies at that inflection point.

While I agree, an SSO login wall is really the most trivial of these enterprise features to implement. Even the most basic SaaS app out there supports it already, and there are enough libraries in every language you can use. So while WorkOS might make things easier in that area, it won't be a game changer, at least not with its current feature set.

Start talking about compliance with a hundred different standards (ISO/IEC, SOC, CSA, GDPR, APEC, HIPAA, FINRA, FedRAMP), data residency, eDiscovery, audit logging, RBAC, invoicing, uptime SLAs, analytics, MDM, disabling features and your customers will be a LOT more interested.

I've seen a SaaS app team who couldn't implement OIDC because their login screen is actually some kind of maven plugin (so they don't control it). They can't move to the latest version of that plugin that does supports OIDC, because that needs the latest Maven version. They're using a BPE (process engine), though, that is end-of-life and won't work with the latest Maven.

They're in dependency hell. So we put their whole app behind a proxy that does our SSO.

We’re just getting started. ;)

I love the idea, and can definitely see the need.

But I always come to the same question with services that provide auth and user management: You pay a lot of money for someone _else_ to own critical information about your customers. What happens if you want to move away and use a different/your own/your customers own service?

Your customer data (at least login) lives in WorkOS' database. How do you get it out? How much does that cost? Are there contractual guarantees around that?

The same goes for your customers integration points. If the customer has to do any setup to integrate WorkOs for your app then moving away would involve them making changes. Not necessarily an easy thing to manage.

Not to be negative: I'd be happy to hear that WorkOS have great processes and guarantees around this.

WorkOS doesn't really own the user management database. It's more like an agnostic API to connect with multiple IdPs through protocols like SAML and OIDC. Identity providers such as Okta, OneLogin, and Azure AD are the ones responsible for storing that data.

Interesting. Perhaps I misunderstood it. So is this roughly a kind of managed Keycloak/CAS setup? With it's own API/well managed client libraries?

Is using their API really any easier than using Rails gems? Some gems are more mature than others but usually it’s easy to drop them in and configure.

They claim SSO takes months to implement without their product. Is that true?

It would probably take months to implement SSO with all of the flexibility and ease of use they offer, mainly just because of the built-in integrations with so many providers. The price is pretty steep though, so this would really only be used by the big bucks Enterprise Software™ guys.

It's not. Implementing the OIDC flow from scratch takes half a day to get working and maybe a week to polish. Using available libraries you can do it way faster of course.

Most enterprise customers require SAML authentication, which is much more complicated with lots of quirks.

Apologies if not the right place for this feedback, but the careers page does not work properly on Firefox 100/Linux - clicking any opening does nothing.

I work heavily with enterprise products. In my experience, when you're selling an enterprise-ready product it's a good idea to QA all public-facing code, even sections of a public website.

This is because I have found many enterprise customers are more interested in maintenance (which can be pre-assessed by looking at support and QA experiences) than they are the actual product.

Anyone know how this compares to Auth0? I like Auth0 because it's free for up to 7K active users. WorkOS seems much more expensive out of the gate ($49 per "connection"?).

What a waste of a sweet domain name

So true.

I applaud WorkOS for the idea (even if I also hate the name). The sheer amount of externally developed apps that don't manage to authenticate to our IdP is staggering. I've had a dozen calls with developer teams, walking them step by step through the OIDC flow and they still can't manage to implement it.

I fail to understand why this is so hard for so many companies. It's really not rocket science.

The signup page mentions using Slack for OAuth, but I don't see that option when I'm trying to set up an SSO integration. I wonder if that's coming or no long available?

I couldn't find any mention to Slack for OAuth in the signup page. Where did you see that?

Either I was hallucinating or it's no longer there. I could have sworn I saw it somewhere between the link to the home page and signing up, but I can't find it now. Will update if it turns up, but apologies for any confusion.

I'm glad the submission title has been updated, as from the page I had no idea what this was.

So, an enterprise authentication service.