When BI Explorer analyzes Kate’s collaboration data, it should receive only the API capabilities she approves—not her password or unrestricted account access. An OAuth scope is a named bundle of related API capabilities represented in an access token. section 11.2.1 section 11.2.2
The client requests scopes from the authorization server, and the resource owner approves them. The resulting token may encode scopes directly as a JSON Web Token (JWT) claim or expose them through token introspection; ACME’s gateway reads them after validation. section 11.2.2
Typical collaboration API scopes include:
- collab:workspace.read — read workspaces and memberships. section 11.2.2
- collab:doc.meta.read — read document titles, owners, labels, and update times without reading content. section 11.2.2
- collab:doc.write — update document titles or statuses. section 11.2.2
- collab:task.read, collab:task.write, and collab:event.subscribe — read or update tasks and register for event notifications. section 11.2.2
Scopes define the broad contour of delegation, but they do not complete authorization. They do not determine workspace membership, document sensitivity, tenant installation, or whether a write includes required attribution. OAuth carries the delegated grant; Cedar evaluates the resource-specific decision. section 11.2.2
Figure 11.4 OAuth roles in action. Kate is the resource owner, BI Explorer is the client, ACME’s Customer Authentication Service is the authorization server, and the Customer Collaboration API is the resource server.
Use the role diagram to trace the grant from resource owner through client and authorization server to the resource server. section 11.2.1
