Yes, this is correct, and that’s how it’s been working in the past, and this is where you start seeing or making some more sense of the existence of the authd. When a webapp needs write access it needs a keypair with safecoins in its balance so it can pay for storage. Otheriwse it can access the network but with read-only access.
The API exposes the auth_app which allows apps to get such keypair from authd (this API does that, sends a request to authd), the user then can allow such request (using CLI auth commands, or SNAP GUI) which results in the authd assigning and returning a keypair to the app.
This flow is when you use authd to give the apps/webapps a keypair to work with, but there are other infinite ways the apps may decide to obtain such keypair, e.g. a hardware wallet (not possible yet due to missing feature in sn_client API), asking the user to enter it, etc…