4 ms·
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 st
by malachygr 8y ago
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 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!
- mrec 8y agoThis 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.)
- malachygr 8y agoRight, in German we say "ultimativ" so that's the reason :)
- danieka 8y agoNice :) The first code example is missing an end ' in the endpoint string. '/some-protected-resource -> '/some-protected-resource'.
- cmpb 8y agoHave 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/ http://hackingdistributed.com/2014/05/21/my-first-macaroon/
- Boulth 8y agoBecause 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/CryptoTools.js#L51 https://github.com/nitram509/macaroons.js/blob/master/lib/Cr...
- programd 8y agoHere is one cautionary tale showing why you would not want to use Macaroons: https://about.sourcegraph.com/go/gophercon-2018-an-over-engineering-disaster-with-macaroons/ https://about.sourcegraph.com/go/gophercon-2018-an-over-engi...
- dwaltrip 8y agoHey 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.