6 ms·

There's a lot of conversation on when should I use JWTs and when not to. But as alternatives go, has anyone tried using Macaroons? They've been mentioned in H

There's a lot of conversation on when should I use JWTs and when not to. But as alternatives go, has anyone tried using Macaroons? They've been mentioned in HN a few times but I've never seen the tech catch up, even though it looks like a very cool way to implement authorization. Is there any particular reason why? Here are some resources I've found and I think Macaroons is a very interesting concept. Even the paper is accessible to someone like me, without any real security or cryptography expertise. Research paper: https://research.google.com/pubs/pub41892.html https://research.google.com/pubs/pub41892.html A new way to do authorization: http://hackingdistributed.com/2014/05/21/my-first-macaroon/ http://hackingdistributed.com/2014/05/21/my-first-macaroon/ (This link has an invalid HTTPS certificate if that concerns you): https://evancordell.com/2015/09/27/macaroons-101-contextual-confinement.html https://evancordell.com/2015/09/27/macaroons-101-contextual-... After I found this, I've always wanted to try it out but haven't had the chance. Does anyone has any experience or comments about it?

hdhzy 9y ago
Wow, what an interesting idea it looks like macaroons resemble HS256 JWTs (no asymmetric Crypto) with claims encoded as strings (except key-value pairs of JWT) that are interpreted by the verifier (you can build more complex claims like login time between X and Y). On the surface it looks like JWT and Macaroons are very similar.
- tptacek 9y ago
  Except that you can't change a Macaroon header and convince either the recipient of a token or the server verifying it that it is instead a NIST P-Curve public key attestation, so they're really only similar if you ignore the many problems of JWT. It's the nature of a grab-bag metastandard that it can be twisted into a poor version of any related standard. That's the problem with standards like these.
  - saganus 9y ago
    I'm not familiar with either the details of how JWTs or Macaroons are implemented, that's why I'm interested in a cryptographer or security expert comment on this. Do you think that Macaroons are a sane alternative to JWTs? or in general, any comments on using them for authorization instead of OAuth2 or any of the alternatives? Edit: I think I do understand that some of the problems with JWT is that they have a lot of moving parts so the attack surface is much greater as well as not helping the developer avoid getting shot in the foot. Macaroons by comparison seem much simpler to my untrained eye, in that they are "just" a chain of HMACs, so that any modification of the different sections of a Macaroon would render it invalid. So why would Macaroons be or not be a suitable alternative to JWTs or other auth methods?
    - kevinburke 9y ago
      if only someone would write an article documenting sane alternatives to JWTs
      - saganus 9y ago
        Maybe I wasn't clear, but I was referring specifically to Macaroons vs JWTs, i.e. Macaroons as an alternative to JWTs. I read your article but didn't find any reference to them, that's why I asked. Edit: Sorry if I came across as dismissive of your article somehow. What I meant to say is that some comment from a security expert, specifically on the Macaroons concept/implementation would be great, because to my untrained eye it looks very nice and secure but then again, I'm not an expert and thus can't trust myself on that.
    - unscaled 9y ago
      It is a suitable alternative, where 'suitability' depends on your needs. For simple session management, it doesn't offer advantage over encoding all your claims as JSON and adding an HMAC-SHA256 MAC. But macaroons come to shine when you need to delegate authority to third parties. Let's say you are logged in to your work calendar and wants to give a third party service permission to read your busy time (but not any other appointment data) for the next 2 months. You take your current macaroon and tack 3 caveats on it: - third_party_service = busy_timer - date_range = 2017-05-01...2017-07-01 - permissions = start_time/read, end_time/read You can do everything on the client side and you don't have to mess with OAuth.
  - hdhzy 9y ago
    You say that the standard is bad and that indirectly caused bugs in JWT implementations but looking at Macaroons examples there are still some corner cases where a programmer can make mistakes. For example this piece of code (fragment taken from [0]), restricts the Macaroon usage to given account... Or does it? M.add_first_party_caveat('account = 3735928559') Only someone familiar with the topic will notice that it doesn't add anything to M as Macaroons are immutable but instead returns a new, adjusted object (the same "issue" happens in Java with BigIntegers). If you know what you are doing you won't make this mistake but in this case you would also have safe JWTs... As far as I can see Macaroons have interesting ability to be adjusted by intermediaries to limit their scope. Say you have Macaroon that gives access to your Gmail account you can "attenuate" it to limit scope only for emails in the next 10 minutes without contacting third party. That'd be very useful for OAuth like flows... [0]: https://github.com/rescrv/libmacaroons/blob/master/README https://github.com/rescrv/libmacaroons/blob/master/README
evancordell 9y ago
You can use the http version until I get some time to setup letsencrypt (feel free to disable javascript/css/etc). I've used macaroons in several settings and highly recommend them. The only thing really missing for "wider" adoption is something like a standard caveat language, the lack of which keeps macaroon use pretty localized to your specific deployment.
- saganus 9y ago
  Thanks for the input! I'm still hoping the tech catches up somehow and then there's probably going to be more people interested in a standardized way to define a caveat. When I was toying with Macaroons some time ago, I thought that I could use JSON to format the caveat and toyed with the idea of defining a set of useful caveats, but never got too far.
  - evancordell 9y ago
    It seems that most people have those thoughts when they play around with Macaroons :) Check out the google group for some discussions: https://groups.google.com/forum/#!forum/macaroons https://groups.google.com/forum/#!forum/macaroons If it wouldn't doom them to obscurity, I'd personally like to see a set of vocabularies that macaroon users can use (a la semantic web). This is probably as simple as namespacing caveats with globally unique identifiers to indicate the vocabulary.
    - saganus 9y ago
      Yes, exactly! I actually did read the whole forum when I found out about them, and that's where I got the idea actually. Not that I went much further than what was discussed, but it definitely planted a seed on my mind... Re: Vocabulary Something like that sounds reasonable. I would just maybe add some sort of SET operations logic that you could use to build more complex stuff. Thus I would be able to delegate to someone a Macaroon that has admin access to all of Project P EXCEPT (or MINUS) access to Project P's children in list L. Or maybe delegate with access to any object in List (L1 AND L2). Sort of like a SQL query (to an extent). At least that was the use case I needed back then, i.e. How to secure an API in a hierarchical way, such that certain user roles can access only certain children of a certain parent node.

hdhzy 9y ago

Wow, what an interesting idea it looks like macaroons resemble HS256 JWTs (no asymmetric Crypto) with claims encoded as strings (except key-value pairs of JWT) that are interpreted by the verifier (you can build more complex claims like login time between X and Y). On the surface it looks like JWT and Macaroons are very similar.

tptacek 9y ago
Except that you can't change a Macaroon header and convince either the recipient of a token or the server verifying it that it is instead a NIST P-Curve public key attestation, so they're really only similar if you ignore the many problems of JWT. It's the nature of a grab-bag metastandard that it can be twisted into a poor version of any related standard. That's the problem with standards like these.
- saganus 9y ago
  I'm not familiar with either the details of how JWTs or Macaroons are implemented, that's why I'm interested in a cryptographer or security expert comment on this. Do you think that Macaroons are a sane alternative to JWTs? or in general, any comments on using them for authorization instead of OAuth2 or any of the alternatives? Edit: I think I do understand that some of the problems with JWT is that they have a lot of moving parts so the attack surface is much greater as well as not helping the developer avoid getting shot in the foot. Macaroons by comparison seem much simpler to my untrained eye, in that they are "just" a chain of HMACs, so that any modification of the different sections of a Macaroon would render it invalid. So why would Macaroons be or not be a suitable alternative to JWTs or other auth methods?
  - kevinburke 9y ago
    if only someone would write an article documenting sane alternatives to JWTs
    - saganus 9y ago
      Maybe I wasn't clear, but I was referring specifically to Macaroons vs JWTs, i.e. Macaroons as an alternative to JWTs. I read your article but didn't find any reference to them, that's why I asked. Edit: Sorry if I came across as dismissive of your article somehow. What I meant to say is that some comment from a security expert, specifically on the Macaroons concept/implementation would be great, because to my untrained eye it looks very nice and secure but then again, I'm not an expert and thus can't trust myself on that.
  - unscaled 9y ago
    It is a suitable alternative, where 'suitability' depends on your needs. For simple session management, it doesn't offer advantage over encoding all your claims as JSON and adding an HMAC-SHA256 MAC. But macaroons come to shine when you need to delegate authority to third parties. Let's say you are logged in to your work calendar and wants to give a third party service permission to read your busy time (but not any other appointment data) for the next 2 months. You take your current macaroon and tack 3 caveats on it: - third_party_service = busy_timer - date_range = 2017-05-01...2017-07-01 - permissions = start_time/read, end_time/read You can do everything on the client side and you don't have to mess with OAuth.
- hdhzy 9y ago
  You say that the standard is bad and that indirectly caused bugs in JWT implementations but looking at Macaroons examples there are still some corner cases where a programmer can make mistakes. For example this piece of code (fragment taken from [0]), restricts the Macaroon usage to given account... Or does it? M.add_first_party_caveat('account = 3735928559') Only someone familiar with the topic will notice that it doesn't add anything to M as Macaroons are immutable but instead returns a new, adjusted object (the same "issue" happens in Java with BigIntegers). If you know what you are doing you won't make this mistake but in this case you would also have safe JWTs... As far as I can see Macaroons have interesting ability to be adjusted by intermediaries to limit their scope. Say you have Macaroon that gives access to your Gmail account you can "attenuate" it to limit scope only for emails in the next 10 minutes without contacting third party. That'd be very useful for OAuth like flows... [0]: https://github.com/rescrv/libmacaroons/blob/master/README https://github.com/rescrv/libmacaroons/blob/master/README

evancordell 9y ago

You can use the http version until I get some time to setup letsencrypt (feel free to disable javascript/css/etc). I've used macaroons in several settings and highly recommend them. The only thing really missing for "wider" adoption is something like a standard caveat language, the lack of which keeps macaroon use pretty localized to your specific deployment.

saganus 9y ago
Thanks for the input! I'm still hoping the tech catches up somehow and then there's probably going to be more people interested in a standardized way to define a caveat. When I was toying with Macaroons some time ago, I thought that I could use JSON to format the caveat and toyed with the idea of defining a set of useful caveats, but never got too far.
- evancordell 9y ago
  It seems that most people have those thoughts when they play around with Macaroons :) Check out the google group for some discussions: https://groups.google.com/forum/#!forum/macaroons https://groups.google.com/forum/#!forum/macaroons If it wouldn't doom them to obscurity, I'd personally like to see a set of vocabularies that macaroon users can use (a la semantic web). This is probably as simple as namespacing caveats with globally unique identifiers to indicate the vocabulary.
  - saganus 9y ago
    Yes, exactly! I actually did read the whole forum when I found out about them, and that's where I got the idea actually. Not that I went much further than what was discussed, but it definitely planted a seed on my mind... Re: Vocabulary Something like that sounds reasonable. I would just maybe add some sort of SET operations logic that you could use to build more complex stuff. Thus I would be able to delegate to someone a Macaroon that has admin access to all of Project P EXCEPT (or MINUS) access to Project P's children in list L. Or maybe delegate with access to any object in List (L1 AND L2). Sort of like a SQL query (to an extent). At least that was the use case I needed back then, i.e. How to secure an API in a hierarchical way, such that certain user roles can access only certain children of a certain parent node.