Re-minting?

[Judson Lester]

I just wanted to check the that terrible idea I've just had is in fact terrible:

Part of the appeal that macaroons hold for me is that they avoid needing database lookups to verify authorization: if you have an appropriate token, you're authorized.

One thing I'd like to do is apply relatively short expiry dates for the macaroons and update that expiry during use. In other words, when a user successfully authorizes with macaroon A that expires in 5 minutes, I'd like to send back as part of the reply macaroon B that expires in 15.

So here's the terrible idea: If I've verified macaroon A appropriately, couldn't I mint a fresh macaroon by enumerating it's caveats into B, except that I replace the "time < ..." caveat? 

Or is it better to have the client attempt to reauthenticate? I'm concerned that I may need to store credentials to do that in an acceptable manner.

Judson

[Evan Cordell]

If I've verified macaroon A appropriately, couldn't I mint a fresh macaroon by enumerating it's caveats into B, except that I replace the "time < ..." caveat? 

There's nothing stopping you from doing that, but there are some nicer ways to do what you're trying to do with macaroons, in my opinion. (It also seems like a lot more trouble than it's worth if you have third-party caveats)

What about something like this: 

• Mint a macaroon with a third party "refresh" caveat (and probably an expiration caveat, but long with respect to the short expiry you want)
  
• Mint another macaroon that discharges the refresh caveat, and has a much shorter expiration (on the order of minutes or even seconds)
• The client sends both macaroons to you for verification
• If both are valid, mint a new macaroon that discharges the refresh caveat with the expire time extended
• On the next request the client will send the original macaroon + the new refresh macaroon (and will have deleted the old refresh macaroon)

There are lots of ways to modify that general idea to suit your needs. I threw together a little example application a while ago that does something similar, but doesn't require a round trip to the server to refresh: https://github.com/ecordell/macaroon-session-example (the use case is slightly different but it could even be layered on top of what I described above as well: say the refresh macaroon also had a third-party caveat requiring a discharge from a local service, with even shorter expiry!)

Hope that helps!

[Tony Arcieri]

On Tue, Oct 27, 2015 at 1:44 PM, Evan Cordell <cordel...@gmail.com> wrote:

What about something like this: 

• Mint a macaroon with a third party "refresh" caveat (and probably an expiration caveat, but long with respect to the short expiry you want)
  
• Mint another macaroon that discharges the refresh caveat, and has a much shorter expiration (on the order of minutes or even seconds)
• The client sends both macaroons to you for verification

I think this is the general workflow you want for these sort of discharges, and the points above are more or less sufficient. It also lets you tie the discharges to your session and/or AuthZ system, so you can query on period intervals whether they have a valid session and whether their access has changed.

You can also refresh on a shorter interval than the expiry, e.g. discharge with a 10 minute expiry window and obtain a new discharge after 5 minutes (depending on how quickly you want session expiration to take effect)

--

Tony Arcieri

[Judson Lester]

On Tuesday, October 27, 2015 at 1:44:24 PM UTC-7, Evan Cordell wrote:

If I've verified macaroon A appropriately, couldn't I mint a fresh macaroon by enumerating it's caveats into B, except that I replace the "time < ..." caveat? 

There's nothing stopping you from doing that, but there are some nicer ways to do what you're trying to do with macaroons, in my opinion. (It also seems like a lot more trouble than it's worth if you have third-party caveats)

 

In retrospect, that's the obvious solution. Thanks for pointing it out. 

There are lots of ways to modify that general idea to suit your needs. I threw together a little example application a while ago that does something similar, but doesn't require a round trip to the server to refresh: https://github.com/ecordell/macaroon-session-example (the use case is slightly different but it could even be layered on top of what I described above as well: say the refresh macaroon also had a third-party caveat requiring a discharge from a local service, with even shorter expiry!)

Actually, I was just looking at that code again - I don't know why using a third party caveat didn't occur to me.

Thanks again,

Judson 

[Tony Arcieri]

On Tue, Oct 27, 2015 at 1:55 PM, Judson Lester <nya...@gmail.com> wrote:

In retrospect, that's the obvious solution. Thanks for pointing it out. 

I think in general if you want to remint credentials and you're not:

1) Adding caveats to an existing Macaroon

2) Periodically reminting short-lived discharges

...you're not using Macaroons correctly. Reminting credentials is explicitly called out as a suboptimal workflow that Macaroons improve on, as reminting adds an extra round-trip:

--

Tony Arcieri