Hacker News new | past | comments | ask | show | jobs | submit login

I remember seeing a talk[1] at Gophercon a while back on how nightmarish macaroons were to implement.

[1] https://www.youtube.com/watch?v=MZFv62qz8RU




First, I don't think that's a good characterization of the talk.

Second, I'm not sure (based on the talk) that I see how they had any of the problems that Macaroons solve.

Third, I think a lot of the trouble they ran into feels like generic "we built our own token system" stuff; for instance, they backed themselves into designing a refresh token system (all their Macaroons had a third-party caveat discharged by their central Rails app, which, without any extra context, seems like a weird choice); similarly, they ran into revocation problems, which they addressed by routing all their requests through their Rails application --- these are just standard "stateless token" problems that you'd run into with a custom JWT solution as well!

(They also issued a whole bunch of long-expiry stateless tokens, and then had to wait forever to transform them to their new tokens, which is a problem every token and stateless cookie implementer has had to deal with).

I feel like they kind of went "full Macaroon", exercising all the features described in the paper, some of which weren't good fits for their problems.

We wrote a survey of auth tokens (it's linked upthread) a year or so ago, and I mentioned this talk, and I remember at the time that it made a dent with me. But we've spent a year rolling out Macaroons and gotten real-world experience with them, and in the course of writing that up I re-watched the talk and was much less persuaded by it --- in particular, I found that much of it was less a critique of Macaroons and more just a good war story about rolling out any custom stateless token scheme.




Consider applying for YC's first-ever Fall batch! Applications are open till Aug 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: