Use macaroon caveats in place of token?

[TonyGiorgio]

Wanted to ask what the point of token was if macaroon is also provided? You could use something very similar to how token seems like it's being used by either saving the macaroon ID in the backend and associating it with permissions or having caveats in the macaroon that represent the permissions. You can do things like one time use or ip locking inside macaroons too.

That way the end user does not have to keep track of macaroon and token, only macaroon would be needed. In place of CreateTokenRequest you could still create macaroons from a macaroon. But it at least gets rid of token so there's uniformity with macaroons. Thoughts?

[johncantrell97]

Yeah, it's definitely confusing and we should probably figure out a way to unite the two auth mechanisms.

Though I should clarify that token authentication is only for the sensei admin service (crud nodes, crud tokens). The token auth isn't used for the node service. In fact, there is no token generated for any of the nodes.

When you first /init your sensei instance it creates an admin access token and returns it to you. This token is used to then manage nodes and other access tokens.

When you create a node it gives you a macaroon and no access token.

Now that the two services are completely separated it's actually probably pretty simple to just switch the access token auth for a macaroon. Can just use the instance_name in place of the node_id for these types of macaroons.

I like it. If you want to try tackling it that's cool otherwise I'll add it to my short-term list of to-dos.

[TonyGiorgio]

Yeah I'm down for tackling it, I was going to end up doing something similar for pLN as well.

Can just use the instance_name in place of the node_id for these types of macaroons.

What is the instance_name that you mention?

Also, do you want the admin macaroon to be able to be reused so that it may also be authenticated for each individual node too? That way an admin does not have to keep track of all of the individual node macaroons?

[johncantrell97]

It's a cli/env var you can pass that just gives the sensei instance a name. Since there's no longer any default/root node there needs to be some kind of "node_id" to use. I guess it could alternatively generate a random key pair to use but a human readable name is fine and might be useful for other reasons.

https://github.com/L2-Technology/sensei/blob/bb197d0a81533e17f1f3be1f020c8acc218436ae/senseicore/src/p2p/mod.rs#L74

You can see the "p2p routing-only node" that all instances maintain uses it as it's node id as well.

So since all macaroons are currently assigned to a particular node_id it would make this change easier if we just used this same node id for the 'admin' macaroon.

I think I prefer it not have access to any of the nodes. I think once VLS lands I'd like to try to keep the nodes as isolated as possible -- It's tough call because I know they share memory so there's really no way to completely prevent access by the administrator anyway.