nick-garfield

Nick here, one of the developers behind Feather.

When we set out to build an auth API, one of the first big challenges was just wrapping our heads around all the various acronyms and protocols. Despite the existence of standards like OAuth, OIDC, JWTs, SAML, etc., authentication is anything but standard. As hobbyist devs, we wanted the interface to be simple. RESTful. Leverage HTTP verbs. We wanted an auth API that we wouldn't have to think about and would save us time.

After a lot of consideration, we settled on creating an abstraction for /credentials. With this, we've been able to abstract away sign-in flows for email+password and passwordless auth. "Just create a credential!" As Josh Bloch once said, “Good names are the API talking back to you”. We're super glad with how credentials abstract turned out. In the future, we plan to extend it for supporting protocols like OAuth as well.

Feather has saved us a ton of time while building other projects these past couple months, and we're happy to share it with everyone today :)

wow, just reading that term "line of business" makes me anxious. I used to work on a global payments platform that supported "multiple LOBs", and it was a nightmare of ifs and switch statements all the way down. The situation was made more difficult by the fact that our org couldn't standardize the LOBs into a common enum.

If you're in the "talking with customers" phase, you should also check out "The Mom Test" by Rob Fitzpatrick.

http :// momtestbook .com (EDIT: I just noticed this is an http site... breaking up the link into pieces for now. Sill recommend Googling the book)

The tldr; is that as soon as you tell someone about your idea, it's going to bias their subsequent answers. They're going to lie to, try not to hurt your feelings, want to get rid of you, etc. So if you're trying to validate an idea, the most important rule is "Don't talk about your idea".

What "The Mom Test" recommends is to instead ask prospective users about their lives and specifically to recall individual moments when they had the problem your idea will supposedly solve. With this "unbiased" recollection, you (as the entrepreneur) have to put 2 and 2 together to figure out if people 1) really have a problem and 2) are open/looking for a solution.

My friend and I got really frustrated with existing authentication providers like Auth0, so we decided to create API called Feather to make it easier to add authentication to our web/mobile apps.

https://feather.id

Still quite a work-in-progress.. but currently designing a stateful React library so that you can drop sign-in, sign-up, forgot-password, session-management, etc. into your app with ~10 lines of code. Plus it comes with a nice admin dashboard for user-management built in!

Hmm that's a bit disappointing.. I feel like Ive and Cook could be wrong on this one. If desktop/mobile is an appropriate parallel, then it seems like they've decided to undercut their desktop machine to have the "ergonomics" of a mobile device while still not being mobile. If the VR headset is a stationary experience, then what's wrong with having a hub sitting around nearby?

This was an amazing post!

100% spot on that the external distractors are easier to manage than the internal ones. A buzzing phone, tempting social media websites, and loud rooms all tend to be relatively easy problems to fix. As for internal distractors, I feel like telling a personal story after reading this.. There are two internal distractors I've recently noticed myself struggling with:

1) A busy mind.

I often find my brain meandering on ideas or conversations completely unrelated to the work I'm trying to do. Daydreaming, imaginary arguments, and unnecessary tangents all tend to creep in (esp in the afternoon for some reason). I'm glad this post touched on Zen Buddhism and the beginner's mind. At risk of proselytizing, I have to say the best way I've found to manage a busy mind is through meditation. Consciously setting aside 10-15 minutes everyday to practice letting go of thoughts has helped build a (tiny) mental muscle which I can sometimes use to bring my focus back on the things in front of me.

2) Alcohol.

This is a bit of an external distractor, but also an internal one. In college, I was able to stay up all night drinking and coding. No longer! I find it amazing how insanely less productive I am even after a single glass of beer. I now get tired shortly afterwards and have immense difficulty focusing. Perhaps as the article mentions, the alcohol is wrapping up my ego in the task at hand. I don't have a drinking problem, but I now solve this by consciously deciding how to spend my next couple hours. "Am I going to grab a drink and take an extended break (perhaps for the rest of the day)? Or am I going to grab a water/tea and continue working?" Gone are the days when I could reliably reach the Ballmer peak (https://xkcd.com/323/).

This is interesting.. I've never heard of the term "tacit knowledge" before, but it makes a lot of sense to me. It particularly reminds me of my experience being on-call at my last company.

Our systems were pretty unstable, and the most stressful part of the job was getting paged at 4am when everything was falling apart, customers couldn't use the app, multiple analysts would be sending messages asking "what's going on?", and as the on-call engineer, I happened to be the last line of defense (the system wasn't managed by a devops team).

In that moment, there's a lot of stuff that has to be done quickly: - orient yourself and figurate out what's going on (even in a sleep-deprived state) - prioritize mitigation over root-cause analysis - communicate early and often with the stakeholders present

This isn't stuff one can pickup by reading a "runbook". It took years of working with the systems, absorbing knowledge from my senior co-workers, and learning from past mistakes to get to a point where these priorities became in-grained in the way I approach outages.

So from my own experience, I would disagree with the definition that tacit knowledge is purely muscle memory or that it can't be improved. One's mindset can certainly evolve and I would consider that as "gaining" tacit knowledge.

I would even say something like music theory can be tacit knowledge. If you talk with musicians that do a lot of improvisation, they can certainly talk to you about music theory, but they're rarely "thinking" about music theory when they play. Just intellectually telling someone how notes/chords relate to one another doesn't transmit that "feeling" one needs to create great music.

What do you mean by DNS-based PKI? That sounds interesting, but I can't quite visualize what that is.

Yeah this is really interesting. The "velocity" of upvotes/comments seems to be more important than the actual raw count.

I'm sure you're right that people occasionally leverage a friend network to upvote content to the front-page. I get the sense this happens a lot on Product Hunt.

But I know for a fact this isn't the _only_ way to reach the front-page of HN because I didn't ask anyone to upvote this post. ¯\_(ツ)_/¯

woah, this is crazy! The flamewar detector (# comments > upvotes) is pretty funny

Haha good point

I've got to recommend refactoringui.com.

They sell a (rather expensive) book on web/mobile app design that explains how to build your design system and use it to create great looking apps. They cover all the bases you would expect like fonts, line-heights, colors, shadows, borders, sizing, working with images, visual hierarchy, using white space, etc. etc.

I'm a developer by trade and I work primarily with one other developer, so we end up doing all of our design work. This book really helped us step up our game and gave us some very simple tactics to use to improve our designs. Imho, it was well worth the price.

https://refactoringui.com

Definitely! And it depends on what key you're storing, but if you use AWS Secrets Manager, you can setup automatic key rotation to run periodically.

Am I understanding the article right: the endpoint would accept any email address and generate a valid JWT without verifying the caller owned the email address?

If so, what extra validation did Apple add to patch the bug?

> No one should be using JWT

What??

AFAIK Firebase doesn't actually offer any real authorization do they? It was some time ago I last built a project with them, but I remember having to create a custom "roles" attribute in the Realtime DB for users.

I agree with this. I think Auth0 at one point was building tools for indie devs, but are now focused mostly on enterprises.

What have you used instead of Auth0?

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?

Thanks for the feedback! We should hopefully find time to optimize the site for mobile in the coming weeks

Thanks for this comment!

We had the same exact experience. Couldn't have explained the state of the docs any better!

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

Apologies in advance if you try to sign in and cannot!

We're running with extremely light infra on AWS and just hit our max-db-connections to MySQL.

Good lesson for the future, because it looks like we're not cleaning up the connections properly!

My friend and I got really frustrated by the available third-party authentication platforms like Auth0, so we began building our own instead.

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!)

The "complex" math in this poster disguises the simplicity of these chords and transitions.. If you're really interested in music theory (and why those transitions sound the way they do), "The Songwriting Secrets of The Beatles" is one of the best sources available today.

https://www.amazon.com/Songwriting-Secrets-Beatles-Dominic-P...