Comment by malachygr | Hacker News Reader

Comment by malachygr | Hacker News Reader

Hi there! From experience we know how hard auth* systems can be. There are a million ways to get what you want. We also see the issue that developers usually start with a least-effort approach (username + password) which needs refactoring later on. The intention of these articles is to give you an overview of what exists and help you choose the best approach with as much information as you can get. We hope that this saves you some time. If you haven't heard from us before, I welcome you to check out our open source products which are all related to auth*: https://github.com/ory

We will plug some of these (and other) open source products in the articles, but we really want to teach you something. There is so much SEO-optimized onboarding (for expensive blackbox SaaS) content with little substance on this topic. We really hope this helps you!

One last thing: We hope it's ok that the other parts are not ready yet. Aeneas (author of the guide) is trying to push out one ~ every month! Getting this content right is a lot of work :)

Cheers!

Hey thanks for posting! Small request: Would you mind adding a date to your blog post? I'm sure visitors from the future will find it helpful.

Have you looked into using Macaroons[1] at all for distributed systems? I used them for a client's multi-site intranet a while back, and it made some of the very complicated parts very simple. I'm just wondering why they never seem to have caught on.

[1] http://hackingdistributed.com/2014/05/21/my-first-macaroon/

Because they have a lot of complexity that, for a code they runs a part of auth logic, is really dangerous.

For example, verification of third party Macaroons requires building a directed graph, that needs cycle detection. No implementation that I've checked does this instead allowing only one level of nesting.

Third party caveats have more problems, if a third party would issue them they need to be standardized but there is no such standard. Worse, even the underlying byte format is not standardized instead there is this de facto standard of using "variable op value" format. But what variables are supported? It needs to be specified or the third party macaroon would be invalid.

If we talk about byte formats Macaroons are serialized using another custom format. Compare this with base64 and JSON used by JWT.

Then there are certain "programming shortcuts" in implementations [0].

I've spent some time implementing Javascript library to build and verify Macaroons from the paper (that is also inconsistent with the de facto implementations) but ultimately I've decided to just use limited subset of JWT. It's just simpler.

[0]: https://github.com/nitram509/macaroons.js/blob/master/lib/Cr...

Here is one cautionary tale showing why you would not want to use Macaroons:

https://about.sourcegraph.com/go/gophercon-2018-an-over-engi...

Nice :)

The first code example is missing an end ' in the endpoint string. '/some-protected-resource -> '/some-protected-resource'.

This looks great! Thanks for putting it together.

(Not convinced about "ultimative" though. I'm assuming you were going for a portmanteau of "ultimate" and "definitive", but I suspect a lot of people are just going to read it as "ultimate" and subsequently remember/Google the wrong thing.)

Right, in German we say "ultimativ" so that's the reason :)

Reply on news.ycombinator.com