Discharging 3rd party caveats with non-Macaroon tokens

[Neil Madden]

Hi,

I have some use-cases I am playing with where it might be useful to combine Macaroons with other forms of authorization. This might be heresy, but has anyone ever looked at supporting 3rd party caveats that can be discharged with other (non-Macaroon) forms of tokens/credentials? For instance, I might want to say that this Macaroon can only be used by somebody who has an OAuth access token from this authorization server with these scopes, or perhaps even lock down a Macaroon to only be usable by “Mary” as identified by some OpenID provider.

Kind regards,

Neil

[Robert Escriva]

Hi Neil,

I've thought about some integration between macaroons and authentication
mechanisms that already exist. The macaroons framework itself doesn't
easily lend itself to having this different kind of third party caveat
without putting some amount of extra verification in the server doing
the verification.

What I would suggest doing instead is writing a proxy service that can
translate one authentication source into a third-party discharge
macaroon. This keeps the core macaroon library free from any complexity
around OAuth, OpenID, or any other framework. Ideally, we could even
have one service (either aaS or individually deployable) that translates
from the myriad of other forms of authorization into the macaroons.

If you do make progress on this front, I (and I'm assuming many others)
would love to hear about progress you've made.

-Robert

[roger peppe]

We have a service that does exactly that. It's at
https://github.com/CanonicalLtd/candid.

The clients don't have a special case for this service. Instead, we
have a standard macaroon discharge protocol that allows a server to
request more information to complete a discharge. The discharge
protocol is briefly described here:
https://godoc.org/gopkg.in/macaroon-bakery.v2/httpbakery#Discharger
and in a work-in-progress specification here:
https://docs.google.com/document/d/1e2Jj4iWxMVVx6KCCBmpyMd8KA-PUDFiqULmr3nmvpqo.
We have Go, Python and Javascript code that supports the protocol.

An old version of the Candid server is running at
https://api.jujucharms.com/identity and there's the more recent
version running at https://api.staging.jujucharms.com/identity (it
will become current once we've worked through a few backward
compatibility issues, RSN :-])

In summary, when a server gets a discharge request and the client
hasn't provided enough information for the server to decide whether to
provide the discharge macaroon, the server can return an "interaction
required" error containing a list of possible protocols that the
client can choose to follow to acquire the macaroon. The result of
following an interaction protocol is a "discharge token" that the
client can present to the discharge endpoint to acquire the discharge
macaroon.

If you're interested, I can go into more detail. We have a white paper
in progress that's long overdue...

cheers,
rog.

[Neil Madden]

Thanks both for the useful pointers. I’ll have a play and let you know how I get on.

Cheers,

Neil