 Welcome to Authorization in Software, the podcast that explores everything you need to know about Authorization. I'm your host, Damian Schenkelman, and in each episode we dive deep into Authorization with industry experts, as I share their experiences and insights with you. If you're a software developer, or just someone that's interested in the world of Authorization in Software in general, you are in the right place. Let's get started. My name is Damian Schenkelman, and today I'm chatting about Authorization and Macaroons with Neil Madden. Founder at Eliminated Security and author of API Security in Action. Hey Neil, it's great to have you here. Hi Damian, it's great to be here. Could you give our listeners a brief overview of your background and what are you up to today? Yeah, of course. So as you said, I'm Neil Madden, and I'm currently running a startup called Eliminated Security. I'm providing kind of application security training on things like JSON web tokens and things like that, and a bit of consultancy. Before that though, I was the security architect for 4DROC, which I worked for a bit over nine years, off and on. I'm also the author of the book, API Security in Action, which was published by Manning a few years ago. And in my spare time, I also a kind of bit of a security researcher. I took kind of a look for vulnerabilities in software. So some of your listeners may know me from a major vulnerability I found in Java's Elliptic Curve Cincture software last year. It's called Psychic Signatures. I'm also quite a long time regular contributor to the OAuth Working Group at the ITS. So I've kind of helped shape some of the more recent standards that have come out of that group. And pretty, pretty active there. That's neat. It seems you've been thinking about cryptography and how to use it to secure the APIs for quite a while, which is a big reason I'm really excited about covering you here. I've been thinking about doing a Macaroon episode since I started the podcast. And when I started thinking about it, I was like, who can I invite? And your name came up in conversations without folks. I'd read your post. So I was like, yeah, and it needs the person to have on here. Could you maybe share with folks what a Macaroon is and why we're talking about it in the context of authorization? Yeah, of course. So Macaroons were invented by Google. They produced a research paper, I think almost 10 years ago now, where they described this new approach to authorization tokens. So they're really, in some ways, they're similar to a JSON Web token or CHOT, but they're much more constrained. They only have one algorithm, and it's a very simple algorithm, but they have some interesting new properties that CHOTs don't have. So in particular, you can add these things called caveats to a token after it's been issued. So with a CHOT, you issue it, issues a token, and then it's kind of fixed for the life of that token. Whereas with a Macaroon, after it's been issued, anyone can add these things called caveats to it, which restrict how that token can be used. So there's kind of this nice thing you can do where you can change the token after it's issued. So we introduced a few concepts there. We talked about JSON Web tokens, and we also talked about algorithms. Can we maybe share what's a JSON Web token? People might not be familiar with it, and also what's an algorithm when we think of the JSON Web token? What's the algorithm? What is it used for? So a few people are familiar with cookies and things like that. So when you go and log into a website, you get a cookie set in your web browser, which kind of remembers who you are. And the traditional way those were done was, you know, you logged in and then details about the user were stored in some kind of backend database and some kind of random ID was generated that was then became the cookie. And then every time you send the cookie back, you go and look it up in the database and find the information. And so JSON Web tokens and things like that are a way to do that without having the database, basically. So you can encode all of the information into JSON or some of the format like that. And then you sign it cryptographically with a secret key to protect it against temporary fortress and things like that. And then that encoded token becomes your cookie or your access token or whatever else you're using for authorization. And then you don't need the database. And so when that token is presented, you can verify the signature check out it been tampered with and then extract the details from the token. So JSON Web tokens support lots of different algorithms. So the simplest one they support is something called a HMAC which sends for hash-based messenger authentication code. We're talking about algorithm for signing the domain you mean, right? Right. So you can sign it either with a single HMAC which, as I said, is a message authentication code where you have a secret key and both the person signing, issuing the token and the person verifying it have to have access to that shared secret key. But then JSON Web tokens also support public key algorithms where there's a private key that signs the token and then there's a public key which could only verify the tokens and then you can distribute the public key to the PI servers and they can verify the tokens with that bit. So Macaroons just use HMAC basically. So it's always based on a shared secret. So this is a protocol for Macaroons but that's the one algorithm they support. And so the issue in the verifier of tokens and Macaroons have to have the shared secret key. On the plus side, you get these nice properties of being able to append these caveats and HMAC is really fast and it's a lot faster than most like public key signature algorithms. Okay. So to recap and let me know if I got this right back in the day, we started storing some big, large string in a cookie and that was a reference to something in the database that represented data about your authentication and your session. At some point we said, hey, can we make this stateless? Stateless is easier to scale because you don't require stating the database. We can just horizontally scale adding more servers. Yes, we can. We can use cryptography instead. So we started storing JSON sign and again, that could be signed with a typical kind of like secret share key or it could be signed using a public private key cryptography. At some point and then you said, okay, that's a JSON web token. The thing about the JSON web token is that once it's been signed by what we refer to typically as a signer or the issuer, it doesn't change and this is where kind of like macaroons come in. You can add these things called caveats that allow you to kind of change the macaroon and in exchange for that you need to rely on using shared secrets. You can't go with the public key format. What's a caveat and how can I use it? What are the use cases for it? Right, so there's a couple of different types of caveats. The simplest ones are what's called first party caveats and then there's another thing called third party caveats which we'll maybe talk about later on. So first party caveats are, they're just a restriction on how the token is used and they are just, in macaroons they're just a string which describes some kind of condition that has to be true when the token is used. In terms of things like cookies or access tokens and things like that that people will be familiar with you could think of it as like a caveat as being so for example like the fiery time on the token. When it's get issued it will have some expiry time which may be like two hours in the future or 24 hours or whatever and you could add a caveat that says actually now the expiry time is only five seconds in the future. So why is that useful you might think if I've got this token why do I want to limit myself to it only expiring a lot sooner than it was to it? Well the reason for this is when you're going to send that token somewhere where you don't fully trust where it's going like you don't trust the network or you don't trust the recipient on the other side so if you're about to make a network request to go to access some API then you've got a cookie or something that's valid for 24 hours if that cookie gets stolen on that request then the attacker can use it for 24 hours until it expires which has come a long period of time but what you can do with macaroons is you can create a copy of that token, that cookie and you can add this caveat saying actually it only expires in five seconds and then send that version over the network and then if somebody steals it it's only good for five seconds and you can add different types of caveats in the original paper they call these contextual caveats you're restricting the token based on the context of the request you're just about to do like if you were doing some kind of transaction you had some kind of unique ID in that request then you could maybe add that as a caveat and then it's only valid but you've still got the original macaroon without those caveats attached to it so you can still use it for 24 hours or whatever and every time you make a request you create a copy of it and you add some more restrictions related to the request you were just about to make and then that means that if those copies get stolen either on the network or because of some institutional coding on the server or, you know, leasing in server logs or all the other ways that these things can happen then what's been stolen is a much more restricted token than the one originally issued It seems using macaroons and some of the use cases becomes interesting and you take advantage of them when we have different parties in the system and the one holding kind of like an original macaroon doesn't have, I'm going to use quotes although people cannot see them high level of trust of other parties in the system but we use you and like, hey, who can issue it and who can kind of like add caveats to a macaroon maybe we can kind of like go a step before and think about an example so what's the story of a macaroon? How does a macaroon get issued and what's a typical party that would issue it and who would it issue it to? Right, so there's lots of different ways and scenarios so they could be used kind of in the same way that JSON web tokens are used, you know for all kinds of different situations so to issue the macaroon you just need to have this secret key that you use to create it and then they have this identifier which is just an arbitrary kind of string that you can put stuff in so that could be something like you could still have a traditional database token and have a 90D that's like opaque and first about or you could put in some structured JSON or something like a jock plain set and then you kind of sign it with your secret key using HVAC and then you issue it and so if you think about the examples so you can use them as a kind of better cookie which was how Google pitched them so you go inside your website your website could use as a macaroon as a cookie and send it to the server which will then send it back you'd have to have some JavaScript on the web client which is then looking and appending these caveats to be nice to think maybe in the future Google could change Chrome's sort of automatically add caveats when cookies were sent in but I don't see them doing that anytime soon and then there's also one of the things we were looking at at Fordrock was using it within the OAuth system so having access tokens issued by an authorization server as macaroons which would then be verified by a resource server so APIs were there was a couple of ways we were kind of looking at doing so as I said before because these are based on shared secret keys you can either trust all your APIs and give them access to that secret key to verify stuff but then they also then have the capability to mint their own access tokens which is more trust than you typically want to give them right and particularly then if any of those servers gets compromised and that key gets compromised then you've lost the keys to your old authorization kingdom really so a different way you can do it is to issue these macaroons as tokens but then still have your API servers call back into the authorization server to validate using something like token introspection which is the standard OAuth API for validating an access token so that was typically used with database backed kind of stateful tokens but you can use it with macaroons as well I mean it's kind of obviously then you've got the latency of these kind of network overheads when you want to validate tokens but you get things like you know these sort of revoking tokens then you can still horizontally scale your authorization server or all the other states that's neat there's a bunch of concepts here and I'm going to try to unpack them really when digging deep in with a few questions so it seems that there are a few scenarios where you might start kind of like issuing a macaroon you talked about too you said you're an app or a server someone starts a session with you you issue a macaroon to the client and then the client sends it back to you with a kind of way using it as part of the cookie they're an API called to the same server and because you issued it you naturally can sign these which means you have the secret to verify them now that's one scenario in that case so let's go that one in particular who is the party that gets the macaroon and who would add caveats like where do you see okay like I'm getting a macaroon from let's say a website that kind of like has authentication they are not delegating with OAuth or anything who would get that macaroon and essentially add a caveat to it attenuate it to share it with another party and what would that party or what could that party be so there's a bunch of different things here so one example is just the client is something like a web app and there's challenge script running in your browser or it could be something like a mobile app things like that and it's taking this token and then it's just doing what we said before so it's adding these contextual caveats before it makes API calls so that as a pure security mechanism just you know if that token gets intercepted somehow or leaked somehow in that request the what gets stolen is less it's less of an impact than this thing you achieved so in that case it essentially it's attenuating or adding a caveat and then it sells for itself so it has kind of like the updated macaroon with some restriction and then that's what's sent over the wire and what you're trying to limit there is if someone can steal that over the wire what they steal is no longer maybe going to be valuable in five seconds or next time is that kind of like one use case yeah that's one use case so it's kind of it keeps the unrestricted version to itself and then it can send this more restricted version over the network or you know because you might as well like a client might get an access token which is valid to add a whole bunch of different APIs right which are sitting in different servers and maybe one different people and so on and so if one of those servers is compromised then when it gets your access token it can use that access token to access all the other servers as well whereas one of the things you can do with caveats is you can add an audience restriction to a token after the fact so the original token might be valid for these five different servers but before I call this one an audience restriction that makes it just valid for them so for instance if you look at like Google cloud for an example they have you know you get an access token from them and you can access like hundreds of different APIs cloud with this token and so you might have a token that can access all kinds of back end services there and that's useful for your app because it needs to access these at different times but when you make the actual calls you can append this caveats thing right now on this call that's only valid so this one API and if somebody steals it they can only access that one API with it in that case you're making the client an issuer let's say the server but let's say the issuer of the macaroon and the client it's a less chatty relationship right they just get the macaroon and it attenuates it when calling the API and server rather than having to go get I would say a more restrictive version each time they want to call one particular API so that you're gaining security by putting the owners on the client to restrict things while at the same time reducing load on your servers in terms of like not having to issue these kind of like attenuated specific versions of the tokens yeah exactly exactly there's also some things you can do when we some more advanced cases when you start looking at these third-party caveats which we haven't talked about yet before we get into third-party caveats which I know are a thing in and of themselves I wanted to chat a little bit about kind of like the OAuth case you mentioned we explored issuing an access token that is a macaroon and you talked about well but you get into the problem with symmetric keys maybe we can talk about typical parties in the macaroon system and typical parties in the OAuth system how could these be the same and what does it mean you also hinted at some of these things like hey if I use macaroons I need to share the secret between the authorization server and the resource server compared for example with the json web tokens is that even possible what are the trade-offs here right so as you said with this shared secret thing I mean when people use json web tokens OAuth what they normally want to do is they have the authorization server has the private key it signs the token and then they distribute the public key to all of their API servers resource servers and they can then validate the token without having to coordinate or talk to the authorization server at all with macaroons at least with the version of macaroons that's been kind of used and deployed everywhere that's you can't really do that pattern because you have to share this secret key so you'd be putting way too much trust in your resource servers then really and so a typical way to use them is you'd use token inspection which is an OAuth standard which is why this is part of the reason why I think macaroons and OAuth work quite nicely together which is that macaroons lack there's no standard for macaroons and there's no standing for kind of these interactions and things whereas OAuth provides this nice framework for how these interactions happen but it doesn't specify what the tokens look like so you can kind of plug in and get the bursts of both of these so what you can do is you can have your secret key is just in your authorization server and the clients talk to it to get an access token and that will be a macaroon and then when your resource servers want to validate that access token they call the token introspection which is a standard OAuth API to validate an access token so they call into it and say hey here's I want to validate it and one of the nice things we were able to do at 4Drop when we implemented this is that the response to that token introspection API is a JSON document that sort of says you know is this access token valid when does it expire what's the audience that it's intended for scopes and things like that and with macaroons what we allowed is people to add caveats that can restrict any of those things so they can restrict the expiry time, restrict the scope and all those kind of things and the authorization server would look at this macaroon that came in it would validate the scope, the signature then it would look at all of these caveats and it would automatically incorporate into the introspection response so as far as the resource server is concerned it just looks like an ordinary introspection response for any other kind of access token but if you've appended a caveat that says this expires in five seconds then the expiry time on the response will reflect that, if you've appended if the original access token had five scopes that it was validated, valid for and you appended a caveat that reduced that to two then the token introspection response will just show those two scopes as being the scopes of the access token that makes sense I can imagine there are some trade-offs there, particularly if we think about how we started the conversation we said we went from cookies with opaque strings that were references to a database to we want to use crypto so that we can scale this and if we go with an approach like this the resource server has to call the authorization server to do introspection which means that there's added latency in that call and depending on where your resource servers APIs are deployed, they might be around the globe they have to call maybe a centralized location, if you have a centralized authorization server it also means that your authorization server becomes kind of like a point of failure for your API how do you think about this trade-offs in the design and maybe what other trade-offs are there when using such at the time those are all really good points that people need to consider so all of those things are true there is some extra latency in the authorization server there is then becomes a single failure where I think it's different from the database approach is that you can still horizontally scale your authorization server so a database is really hard to horizontally scale anything that has state that you have to kind of synchronize and look it up and here you can distribute that secret key to all your kind of cluster of authorization servers and you can scale those so even though you're calling back into this authorization server all it has to do is validate the signature right so it doesn't have to look repetitive so there is still the opportunity for more horizontal scalability and in return for that you get some nice features so it's easily generally to do checking whether the token is being revoked and things like that there's also something I think which is not talked about often in OWAS is the kind of traditional software engineering idea of encapsulation which is you know the idea that you should hide the details of things that you might want to change later one of the things you might want to change later is what kind of access to it what kind of format so if you say access tokens are Jots and all of my API servers know that and they will validate them then it's really hardly wrong to ever change to something other than Jots whereas if you're calling back to the authorization server to interest your tokens then what format those tokens are is kind of encapsulated by the authorization server and is hidden from those things and so you can make a database back token change it to some like a Macaroon maybe later on each side actually Macarons were wrong I would change it to Jots and your API servers don't have to change because the authorization server is handling so is these trade-offs and the trade-off for that is that you have this added latency and potentially and those kind of things yeah I really like how you not only kind of like added to the trade-offs but also explain kind of like this notion of encapsulation at the end of the day I think you have to make choices that are formed for what you think your application needs for example if you think about like if you're doing authorization for V2E application well your employees are rightly going to continue using whatever you're doing because first of all they're stuck there and also it's not latency sensitive at the same time if you think about like maybe e-commerce where it's well known that latency affects the conversion and how much people buy that you might go with another approach and yeah trade-off and encapsulation but you gain performance that's very interesting I want to kind of like now double down on some of the capabilities of Macarons because we've talked about the caveats and the first party we've talked about how you can use them for verification and particularly in the odd flow but you mentioned this thing about third party caveats and we talked about it a couple of times and now I think it's kind of like time to open up that box what is a third party caveats and how does it kind of like come to a table right so third party caveats are really kind of amazing and also a bit scary at the same time so with first party caveats we had it as like they're just a a condition they're just kind of some string that you have to check time with a third party caveat the idea is that you're adding a condition to a token that requires the client to go to some third party service and get a proof that it satisfies some condition so it's not something that the resource server or the verifier can check themselves locally it requires some other service so a classic example that's kind of used a lot which I think helps illustrated but perhaps it's not that real world is the idea of like proving that you're over 18 or over 21 so you're going to use this this macaroon to go and buy some alcohol from an online store and that wants some kind of proof that you are old enough to buy this based on local you know or whatever so the idea is it can issue this token and it has this third party caveat that points at some sort of government age verification service and so you as a client then have to go to this service and get this proof which is known as a discharge macaroon that proves that you are you know over 18 or 21 or whatever it is and then you present both your original macaroon and this discharge macaroon when you want to buy your alcohol and it can tie the two together there's some clever kind of cryptography that's used for that well so another use case where Baldire was kind of working on that's Fordrock which this was when there was a lot talk around sort of open banking and things and you know PST2 and these kind of financial APIs that wanted to fine grained authorization of transactions and so there was a demo I came up with which was around that kind of thing so the idea is that you would have you'd install like a banking app on your phone and then you do a normal OOS too slow for that app to say yeah I want to be able to issue you know transactions from your bank account and so you'd approve that as a normal OOS too slow and you'd get a macaroon access token but you don't want to just let that app just initiate whatever transactions it wants you want to be able to actually approve everything it does for individually and so you can attach a third party caveat to that access token that requires it to go to a separate transaction authorization service every time it wants to perform a transaction on that transaction authorization service would go and actually you know communicate with the user say you know this app is trying to transfer $2,000 or whatever to this thing is that okay and you know you'd approve it on your phone or whatever and then once that was all approved this transaction authorization service would issue this discharge macaroon which authorizes just that one specific transaction and then the app can then present these two tokens together to then go and actually to the bank to actually go and initiate this transaction and so you get this kind of long lived access token that authorizes the app to even start initiating a transaction to even ask for a transaction and then you get these short live discharge tokens that approve the individual ones I get it, so the client seems to have kind of like an incomplete puzzle that the server will then verify and it needs to figure out how to put this puzzle together and you mentioned a couple of cases the decovernment age verification service the financial transaction approval how does the client put the puzzle together right, so the way these third-party caveats work is that the caveat when whoever creates the caveat adds it to the original macaroon they create a new secret key and that secret key gets encrypted and added into the caveat in a way that the verifier of that macaroon will be able to recover it and nobody else can and then when the client sees this caveat on the token it knows it's going to have to go and fulfill this requirement but it can't access that secret key so what it has to do, there's a location hint which tells it where to go and get this track route and there's no actual standard in macarons for how this happens so there's a bit of some missing gaps here you have to come and invent your own conventions for this at the moment but basically the client will go to this URL and it will present this caveat to the URL and that service, that third-party service of that and that URL will then check does this client satisfy this caveat and it will be able to understand what the caveat is that service will also be able to well there's a couple of ways this happened but often it will be able to decrypt something to get this secret key so if it's satisfied, the client satisfies the condition that's in that caveat then it can recover that secret key and it uses that secret key to create a new macaroon which is called the discharge macaroon and then it issues that discharge macaroon to the client and that's its proof that these things happen in the original macaroon in this discharge macaroon to the API which then verifies it and as part of its verification and from the original macaroon it will decrypt this secret key and then it can go hey look I've got this discharge macaroon to respond to this and I'll use the secret key to verify that discharge with it that's kind of mind-blowing itself where it gets even more mind-blowing so if you want to decrypt yourself a macaroon and you can add more caveats to that macaroon so including new third-party caveats so in general you might have this tree of caveats that have to be verified you might end up with a tree with a very long chain of things to verify and ultimately it seems that there is no end to it you could keep adding macaroons to it you also mentioned that there is no standard on how to agree on a location and essentially how to get a discharge macaroon for a third-party macaroon to be able to fulfill the caveats show that you are proving that it's successful what other things do you kind of need to informally agree on a system to make macaroons work right so this is in my opinion the biggest weakness with macaroons at the moment is that when you go and look at something like this web tokens is an RFC that defines stress web tokens and then there's like four other RFCs that it builds on that define all the cryptographic algorithms and things like that there is nothing like that for macaroons there is the original research paper and then there was a kind of de facto standard implementation that was done called nib macaroons that's been kind of ported to different languages but a lot of these details are just left blank so things like even for first-party caveats they're just strings and what those strings are is not specified anymore so it's not like with joc planes where you have like an XP fame that's an expiry time and things like that so that all has to be agreed so in 4DROP when we did our implementation for OAuth we base those things on existing things around Jocs and so on so if you want to restrict the expiry time of 4DROP access token macaroon you add a caveat which is a little jason object with an XP thing which is going to be an expiry time likewise you order if you want to AUD if you want to restrict your audience scope if you want to restrict scope things like that so we kind of based it on that as a standard but that makes us non-standard with other macaroon implementations which use other ways of doing this and the same with these third-party caveats there's a format for how you kind of encode the caveat and you can have this little encrypted key and some little identifier that gets given to the third-party service and you can put a location hint in there which kind of tells the client where it has to go but what it does when it gets to that URL is completely unspecified you know does it do a post though does it send something jason how does it communicate this caveat to it so all of those details and even in 4DROP we never really got around to formalizing what those details would look like third-party caveats sort of left except none of a work in progress I think I don't know whether they've looked at more work on things so yeah there's a lot of kind of grey areas here where at the moment they work better in kind of closed ecosystems where you can control all of the parties and you can nail down these details yourself I'd like to think if macaroons catch on that there'd be more standardization effort around this and they'd mature and these connotations would get sorted out let's hope for the future but at the moment yeah you need to be aware of these what implementations of macaroons in the wild are you aware of yeah so there's there's a few I'm aware of there's not that many at the moment again this is flex the kind of maturity level that they're at at the moment so you know Google came up with them and I'm not aware of Google actually using themselves anyway so 4DROP obviously we added them I know some customers were looking at them all the time I left I don't think any customers had gone live with macaring implementation but certainly some were interested there's a few things I'm aware of so the Lightning network lightweight transactions on top of bitcoin that uses macaroons and it uses the party caveats for like micro payments so you can have like invoices as a party caveat attached to a token and then when you pay the invoice you get the discharge macaroon that cashes it out and then you can use that so that's kind of a nice thing I know Ubuntu Linux they have their Ubuntu one service which is like their cloud service that's like their single sign-all service behind there was all dealt with macaroons in the background this kind of we don't find any mention of it in their documentation but if you go and look on Stack Overflow for like developers saying oh I got this error message from the service you can see mention of macaroons all over the stack that's all built on macaroons as far as they understand or at least was there's a version of macaroons a newer version called biscuit which we haven't really talked about yet so some people got you know disappointed with these restrictions of macaroons to only be the shared secret and they came up with this thing called biscuits which is like a public key version macaroons so it uses public key signatures it's a bit more expensive to do things you know public key crypto is more expensive than things in some different trade-offs they've done some interesting things around there they have like a they define a really interesting format for caveats based on this thing called Datalog which is and if anyone's ever kind of done prolog logic programming at university and things like that so Datalog is like a simplified version of prolog so you can encode some really complicated and interesting authorization rules in biscuits so there's biscuit then and that so there's a company called Clevercat Cloud who were involved in biscuit and they use biscuit then in a lot of their services as well as they share their class services so yes and those are the main things I think I'm aware of maybe others that I don't know of yeah I think biscuit kind of like opens up a whole new path to go down towards and that might be a very very good topic for a future episode the last thing I want to ask is kind of like the flip side of that question well should a developer or a team use macaroons what problems should scream macaroons at them and what production recommendations would you give them to basically get a system working and not have issues so I think maybe one of the things I think that works really well for macaroons is when you want to kind of harden the security of the system but you don't want to deploy something more complicated so by that I mean there's a lot of work now looking at things going beyond bearer tokens so all the stuff until so far they're bearer tokens if you they're like cash you know if you have them you can use it and so if somebody steals it they can use it as well and so there's a bunch of standards around this so tying access to things like TLS certificates or the standard depop now dynamic proof and possession and things like this which you try to harden these tokens and add more security by tying them to some kind of private key to it so you can't just use the token you also have to have this private key that you sign something or you set up a TLS session or something like that but the problem with these kind of solutions is that they're really hard to deploy after the fact because you have to kind of upgrade everything it wants your authorization server has to issue these kind of bound access tokens which are bound to keys your clients have to know how to address these access tokens how to manage all the keys how to then prove possession of the private key when they're doing stuff and all your resource servers need to know how to verify those things if you're using the token inspection we were talking about before where your servers are calling back into the authorization server then you can switch to something like macaroons and it's kind of transparent to most of your software so your authorization server can start issuing access tokens macaroons and nothing else needs to change initially so your resource servers that are updating the tokens they're still just only token inspection it just looks like another opaque access token to them the clients can treat it like an opaque access token but then you can harden things slowly so you can change your client form at the time to start adding contextual caveats before what I'm saying before they make requests and so you get some of the benefits then that these are kind of hardened tokens that if they're stolen they're harder to use they're kind of induced skunk and things like that so that's kind of one of the nice things I think using them and then some of the things around these kind of fine grained authorization things but before we search caveats and things like that in terms of like production sorry to interrupt like how should a dev that maybe is not an expert in identity and security think about this because on the one hand macaroons offer these capabilities in an implementation matter that's probably simpler but if you look at standards if you look at the open ID working group and so on you get guidance for like the D-POP stuff so there's also some things to balance there maybe yeah definitely I think that is there's a trade-off I think at the moment so where macaroons are on their kind of level of maturity I would say I would recommend that they be used only in kind of clones ecosystem internal deployments at the moment hopefully over time we'd see them mature more and some of these standardization gaps kind of filled in and then they might be more suitable for you know deployments externally facing deployments where you have more different actors involved in different parties involved so at the moment at the moment yeah I would definitely recommend with the level of maturity the technologies that you try and deploy them if you're looking at deploying them in an environment where you control all the kind of moving parts make it a bit easier so I think there's also like in terms of technical things that there are some recommendations so the fact that it's all based on this shared secret key means that these keys have to be really protected and so you know you need to look at key storage and key rotation really important things to look at and making sure you're not using the same key for everything in your entire state you're kind of setting the keys and you know I use this one key for signing macaroons for these APIs and use another one for these other ones and there's also there's a really great talk from a few years ago one of the few kind of real in the trenches reduction deployments of macaroons it's by tests renecened I hope they pronounce their name correctly a few years ago and that was on a kind of it's like a real it's a failure case really of wearing macaroons but there's some really good lessons yeah yeah I saw that one I'm going to add the video to show notes here so one of the things they did there was they kind of they made a mistake with third party carriers basically and this is kind of really instructive I think in that they they had this kind of production or service that was all you know designed to handle a lot of scale and handle a traffic for their systems but then they added a third party caveat that required clients to go to what was basically a toy kind of I don't know it was a toy but it was a small scale kind of Ruby on Rails app that just hadn't been sized appropriately to deal with the amount traffic it was then going to do and what you've basically done then is create like a production dependency of your auth service on this tiny little app that is not scaled appropriately for it and so every time that app came down you basically took out auth for everything really yeah I think it was exactly what you said they had they were validating macaroons on their API but they had a third party sort of caveat on the dashboard and the reliability capabilities of those components were fairly different which is common for almost all products and that kind of like was a big issue that they had yeah so yeah I think generally my advice would be to I feel first party caveats are a lot easier to understand and a lot easier to want to deploy and read about third party caveats are kind of like you read about them you go wow these are amazing and you think of all these ideas things I can use them for but actually they're also a good way to kind of shoot yourself in the foot so you know maybe it should be something that you get some experience with the technology first then gradually introducing yeah typical with the great power comes great responsibility yeah it's been amazing to chat with you about these topics you know a lot and you can clearly explain them in detail in layman terms so I really appreciate it I'm really happy we got to chat about this and maybe in the future we can do another episode with biscuits yeah yeah well yeah it's also I'll betray a bit I'm going to be presenting something hopefully at the old security workshop in London which is kind of my own take on some of these things yeah definitely and we can add that to the show notes once that becomes public and we make the show this episode of a load great it's been great having you Nin I really appreciate you taking the time for this and hopefully every listener here had a good time learning about macaroons and how you can use authorization thanks a lot brilliant it's been great staying on thanks for telling me that's it for today's episode of authorization in software thanks for tuning in and listening to us if you enjoy the show be sure to subscribe to the podcast on your preferred platform so you never miss an episode and if you have any feedback or suggestions for future episodes feel free to reach out to us on social media we love hearing from our listeners keep building secure software and we'll catch you on the next episode of authorization in software