It's a RESTful server-side API for adding user authentication and authorization flows to your apps.
We've been taking a lot of inspiration from Stripe and mostly just wanted to use an auth service with docs like Stripe :)
(Please note this is still pre-pre-pre beta. The docs are incomplete and we have yet to even integrate it with our own apps, so please don't try to build an app with it yet!)
I applaud this and wish you luck. I'm a big cheerleader of Auth0 and have used them in the enterprise setting and in side projects. They do a lot of things right and have such promise for becoming the "why would you choose anything else" solution. They have all the mindshare of JWTs by owning jwt.io. But I must say that the documentation is truly awful, and I think that leaves them vulnerable for a competitor.
The core API docs are good, like the Management API Tester page. But the walkthroughs and general documents are full of broken links, inconsistent use of language, and varying levels of precision in how things are explained. You end up Googling for answers, finding community responses, and having to piece things together.
The way things are called APIs versus Applications is confusing no matter how you put it. Then they are sort of ambivalent in places. For example, look at the SPA guides. Sure, it'll walk you through the Implicit Flow for SPAs, but elsewhere they second guess themselves and say you shouldn't use Implicit Flow for SPAs. Instead, they say create a "Normal Web App". But good luck finding that specific article again just because you came across it once!
If anyone in Product or Biz Dev at Auth0 is reading this, I would urge you to make a case for "even easier mode" that abstracts a bit more and comes with better documentation. I found myself doing so much token management and head scratching about ID versus access tokens that I felt like I need to be a technical expert on the standards just to follow the directions and feel like my app is secure.
Auth0 has potential to actually solve identity in an easy way, but they are not meeting that promise right now, and that is your opportunity.
Hi psankar, we ran across Ory when we were doing our initial "does this exist?" Google search, but haven't actually looked into that project too deeply.
And we'd never heard of Keycloak before, so thanks for pointing them out to us!
Have you ever used or built with either platform? If so, what was your experience like working with them?
I have used (and still using) keycloak and gatekeeper for some projects which we use in prod as well. They are very good and stable, but require a lot of memory. I came across ory when I was searching for alternatives for keycloak. Keycloak is done in Java and the JVM is quite hungry. Also, there are no official helm charts etc. and the project does not feel cloud native. However, when the alternative is choosing auth0 and paying a lot of money, can't complain about keycloak.
I already think of Auth0 as being the stripe of the auth world. What frustrations did you run into with them, and what are your goals to differentiate with feather?
I really thought the same when we first integrated with Auth0 for one of our projects! Most of our frustration with them boiled down into 2 points:
1. The Auth0 universal login solution is not "white-label".
It requires pushing users to an auth0.com pop-up page which has rather limited customization options. Granted they do allow their customers to upgrade to "custom domains", but they up-sell on this point (minimum $23/month) which doesn't make it ideal for us bootstrappers just wanting to get a demo running.
We additionally had a handful of users mention our login flow felt insecure. We determined this to be more imagined than factual, but figured it was a result of the change in design language between our app and the auth0.com pop-up. It was particularly acute when transitioning from native iOS to a web pop-up when entering sensitive information.
The underlying feedback we kept hearing around the login flow was along the lines of “why am I giving my password to this sketchy-looking website rather than to your app?”
2. The Auth0 docs and interfaces are a maze!
We had a terribly difficult time piecing together tips and footnotes from the community support forums and tutorials on Google to complete the information provided in the docs themselves.
There were a number of steps we needed to implement which were completely omitted from the official docs. We found others were running into the same problems as well on the community support forums.
For us, this essentially resulted in a feeling that Auth0 was letting too much complexity bleed through the interfaces for the developer figure out themselves.
—
So these are the two driving reasons we started hacking around on Feather:
- To have a truly white-label auth API
- To have more intuitive interfaces and documentation
https://feather.id
It's a RESTful server-side API for adding user authentication and authorization flows to your apps.
We've been taking a lot of inspiration from Stripe and mostly just wanted to use an auth service with docs like Stripe :)
(Please note this is still pre-pre-pre beta. The docs are incomplete and we have yet to even integrate it with our own apps, so please don't try to build an app with it yet!)