Skip to main content
Hookfish uses the word “scope” in two security systems. Apply both systems, but do not treat them as interchangeable.

​
Resource scopes

A Hookfish resource scope controls which connection IDs, dynamic providers, and vault paths a broker access token may use.
Resource paths are slash-delimited identifiers owned by Hookfish. A scope of acme/payments/** covers the exact acme/payments path and its descendants. It does not cover acme/payment-tools or another path where the same text appears later. Use resource scopes to give a service access to one subtree without sharing the root HOOKFISH_API_KEY. See Token scoping for minting, delegation, expiry, and revocation.

​
Provider scopes

An OAuth provider scope controls what an upstream provider token can do. Pass provider scopes when you start authorization:
The provider defines these values. Hookfish passes them through the provider implementation and records the granted scopes with the connection.

​
Apply both layers

Suppose a worker has a broker token scoped to acme/engineering/**. It can retrieve the provider token stored at acme/engineering/github, but it cannot read acme/finance/github. The retrieved GitHub token can perform only the operations allowed by the GitHub scopes approved during consent.
A narrow resource scope does not compensate for broad provider permissions. Narrow provider permissions do not prevent access to sibling Hookfish connections.