3 ms·

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 https://w

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 https://www.youtube.com/watch?v=MZFv62qz8RU

tptacek 3y ago
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.

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 https://www.youtube.com/watch?v=MZFv62qz8RU

tptacek 3y ago

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.