Skip to main content

Permissions & scopes

What a request can do is determined by two things: your access to the resource, and the scopes on the token you use.

Resource access​

Authorization is based on the projects and workspaces you belong to. A token can only ever reach resources that its owner has access to — for example, you can only read a connection's details if you have access to the project that owns it. This check applies regardless of a token's scopes: scopes can narrow what a token may do, but never grant access to something the user cannot already reach.

Scopes​

When you create a personal access token or an OAuth client, you can assign it a set of scopes to limit what it may do:

  • A token with no scopes has full access to everything its owner can reach — treat such tokens like a password.
  • A token with scopes is limited to those scopes, so you can issue a narrowly-capable token for a single integration and reduce the blast radius if it leaks.

Scopes are sent space-separated when requesting a token, and a request must carry every scope it needs.

tip

Prefer the most limited token that still does the job, give each integration its own token, and set an expiry. If a token leaks, revoke it and issue a new one — see Authentication.

Audience-bound tokens​

For the MCP endpoint, tokens can be audience-bound using an RFC 8707 resource indicator: request a token with resource=https://api.attlaz.com/mcp, and the resulting token carries a resource:<url> scope that restricts it to that endpoint. A token without the matching resource scope is rejected with 403 when used against /mcp.