I'm part of a small team that works on portier[0], which is what one could see as open source alternative to Auth0 (it's not the same thing, and it is more inspired by Mozilla Persona, but close enough). It's a service, as we run a broker online for everyone who wants using it, and the whole concept is having self-hostable brokers that handle the login of users (via email or Openid).

But: While that broker has a proper and simple API one can use to use the service with every language, it is still so much easier to just include a library/module that does that for you. Interpreting the jwt, fetching the jwk to check the signature, packing the request to the broker properly. We currently have one for Python, node, php and ruby/sinatra. They are not all at the same level, the one for sinatra does almost all the work for you, while the the python library is more a set of helpers.

And I don't think that's something weird we're doing, look at services like stripe or superfeedr, they all have language specific libraries to make calling their web part easier.

So what I'm saying: If you run a service that targets devs you might still end up writing language-specific libraries. And I don' think there is much keeping language-agnostic services from happening, as there are a lot of them.

Edit: Though open source there is less, right. I think that's a mixture of the skills you need (having a proper server online and programming the software, not every team can both), the popularity of self-hosting in that community, and that it might cost money to run the online service.

[0]: https://portier.github.io/

Regarding writing interfaces for the service, that's fine too. It's just an easier way to integrate with a service. But there's a big difference between writing a service interface and a library that implements the service's functionality.

We do have plenty of open source services (e.g: Zookeeper, Redis, Kubernetes), but few product level like Stripe/Auth0. Yet there's a lot of duplicated effort in things like writing ecommerce/forum/blog/geolocation/social software. I wonder why we don't have more of these.

If you are currently using a library that operates synchronously on in-memory objects and offers an idiomatic API in the language of your choice, switching to a web service may feel like a bucket of cold water because suddenly you're dealing with an async-only interface that sits behind a slow socket and requires serializing everything to a lowest common denominator API. It's a huge tradeoff that requires serious justification.

Back in 1990, there was an industry standard called CORBA that attempted to turn libraries into services: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

There's a reason why we're not using any CORBA-based software. (Well, the GNOME desktop was based on it for some time, but they gave up eventually.)

But gradually, I got used to the services based architecture, where something as simple as presenting a login page would lead to dozens of REST API calls back and forth between various backend services.

I am not saying that one approach is better than another. I would have to dedicate a separate comment to discuss that. All I am saying is that developing an entire software system composed purely of generic services with HTTP based REST APIs indeed exist and are very successful in very successful companies.

Here's one: Money.

A service will cost me (more) money. A library I can deploy on already-existing infrastructure. Keeping in mind that "Cloud" is 3x to 6x more expensive over running in house, this is a significant drawback.