Authentication and apps

I remember from a few years ago apps had a identifying triplet: vendor, name and ID. This can now too be found in the APIs. If I understand correctly, the authenticator will hand out (sub)keys (?) to apps that identify themselves with that triplet. I assume these might have a balance so that the apps can then connect to the network with the provided keypair and access the network.

Is this correct? Could someone give an overview how it currently works (in terms of Rust/API) and perhaps even elaborate on how it’s envisioned to work?

I know it’s a little early for guides and detailed documentation on specifics, but perhaps I can be of more help with a better understanding than the high level view:

Bonus questions/thoughts:

  • Then, is the browser considered an app in itself? Will the apps/sites that run in the browser be considered sub-apps of the browser, or will the browser proxy the app authentication requests to the authenticator directly?
  • What’s to prevent apps from identifying with a fake or different triplet? Can I use the CLI triplet and possibly profit from the already given permissions/keypair?
  • The Wallet is a container type on the network. But isn’t it better to have something like (Bitcoin) hardware wallets where the addresses/keys are derived from the master (in-memory)?
3 Likes

I’m unsure 100% of the plan here (@bochaco may recall more). We could do that yep. I think the safest way of doing this would be for requiring the authenticator to request user confirmation, and also note it’s being _re_requested by a known app. (Apps should ideally store their keys).

It is at least one option. Tokens was to be involved her,e but that’s been very heavily backburnered for now.

It’s worth noting that the authenticator itself is just another app (one that manages app keys, your ‘main’ wallet, and would top up app’s walletseg). So we’d want to try and avoid having special network functionality (in so far as makes sense), for app keys. They should be keys like any other.

So there’s nothing to say that an app couldnt provide it’s own (network compatible) keys eg, and just ask to be topped up, and be given access to data from the authenticator eg. (am I making sense?)


Yep, it’d be an app like any other. How it’s set up at the moment is that it forwards requests to the authenticator for the webapp.

Nothing at the moment. It’s not a security layer. It’s more informative for the user (at least in theory, i think).

You could. Ideally it should be made clear enough that some app that sez it’s CLI is asking for perms again. And with a note like "if you’re not using the cli and did not expect this… deny this request.


That’s the jist of things at the moment. The auth as app is pretty new (before there was a lot of custom networking code just to do this). So the actual ins and outs of ‘apps’ could be handled / managed by any ‘auth app’, using different strategies. In the end it’s about supplying keys…


The wallet container is just a way of organising keys. It could be something local. It’s not tied to payments in any way beyond facilitating them in some apps.

In the end, hardware wallets, signing etc should be done outwith of the sn_client lib (right now you have to pass the SK in… but we have branches working to remove this; just not a prio right now). Once that’s in signing could be done however, and multisig, would be an app consideration… just organising the signing of the bytes for a request.


Bit of a scatter of ideas there, I hope that’s at least a bit helpful.


Ah, forgot this wee file has example of how CLI auths

3 Likes

Thanks @joshuef. I was wondering about this too.

My feeling is that each web site should have its own identity as an app. Giving the browser access, is very broad and is arguably just a container for loading web apps. Some of these web apps will be more trusted than others. You wouldn’t necessarily want one web app reading/writing private data from another either. You would want each sand-boxed.

Clear net web apps already follow this sort of security model, with the app hosting its own data (somewhere!) and not interacting directly with one another too. Therefore, this would seem natural.

Maybe the browser should be considered its own app for configuration, bookmarks, etc, but those features are external to web apps and should probably be isolated.

1 Like

Thanks @joshuef, very helpful!

I fully agree with the network being agnostic about apps. It’s just about clients using keys. It’s a sensible and clear separation between the network and application layer.

The APIs the way they are now is quite sufficient I’d say, based on your explanations. The Developer Experience can always be changed a little with respect to this app authentication flow.

(When you said the authenticator is just an app I struggled a bit to see it that way. Although I totally understand what you mean, I like to distinguish between, let me call them, a ‘(raw) client’ and an ‘agent’. (Though this is typically me struggling with terminology/standards/protocols/definitions.) From the perspective of a Rust developer using the sn_api, all mentions of ‘app’ relate to the authenticator, so the authenticator must at least be a special kind of ‘app’.)


Interesting take, hadn’t thought about that yet but makes a lot of sense.


I just replied to this other thread, but is has info related to this topic too: Adventures in Rust, Node.js and Safe - #14 by bochaco

I may be repeating some of what @joshuef said already, but putting this simple is to think that you can use Safe without authd and without the Wallet container stored on the network. Every request/message you send to the network has a signature the network verifies and if it’s valid the operation is executed. How the application generated the signature doesn’t matter to Safe, the app can hold the keypair locally, grab it from a remote service, perhaps it doesn’t even have access to the secret key as it uses a hardware wallet to generate the signatures, all the network cares is about the signature to be valid.

The authd is just another app to help users to administer these keypairs, it assigns a different keypair to each app the user has authorised to with the allow commands and API.
The triplet (vendor , name, id) you mention is again something only the authd cares about, to map each keypair to each app the user has authorised in the past and so to give the same keypair each time the app requests it.

Yes kinda, it just needs to expose the service on a JSON-RPC over QUIC endpoint as the authd does, in this way the authd-client API can talk to it.

3 Likes

Perhaps this thread is a good place for some info about what the different APIs we currently have in sn_api repo are. There are currently three different APIs:

  1. The API for regular Safe applications which read and write data to Safe. This API gives you all the functions needed to manipulate data, with the additional auth_app to obtain a keypair from authd, and connect for connecting to Safe (providing a keypair if write access is needed).
  2. An API for Authenticator apps, like sn_authd. This is a small API which exposes functions to create, read and update a private container on Safe where to store the set of keypairs the user administers for his/her apps, as well as some utiities to parse/generate messages that can be received/sent on an RPC mechanism like what authd does with JSON-RPC over QUIC. The container with keypairs is stored on a location derived from the passphrase and password provided by the user.
  3. An API to communicate with an Autneticator through JSON-RPC over QUIC. This can be used by apps which can manage an Authenticator app, as an example CLI uses this API to start/stop authd, to send a request to create a Safe, to allow/deny an app authorisation request, to lock/unlock a Safe, etc. This is also the API that SNAP uses, both the $ safe auth commands and SNAPP act simply as the UI of authd using this API to communicate with it.
5 Likes