An API key is a shared secret: a value presented to an API as evidence of an established relationship or identity. Its security depends on secrecy. An identifier that can be guessed, intercepted, or reused can let another party impersonate the requester, so confidentiality in transit is essential. section 3.6.1 section 3.6.2
A bearer access token plays a related role at an API boundary: the client presents it, and the gateway validates it before processing the call. Unlike an identifier-only secret, an authenticated token is issued after stronger authentication and can represent a completed authentication event or a delegated grant. section 3.6.2 section 11.2.4
Treat a presented API credential as only the outer boundary of access control:
- Validate its signature, issuer, audience, expiration, and scopes at an enforcement point. section 11.2.4
- Identify the subject or integration principal represented by the credential. section 11.2.4
- Derive the requested action, resource, and relevant context, then evaluate policy before allowing the call. section 11.2.4
- Keep scope-based API access separate from detailed decisions about particular actions and resources. section 11.3
Delegated API access
A reporting client obtains an access token after the resource owner authenticates and approves access. It later sends `Authorization: Bearer <access_token>` to the API. The gateway validates the token, constructs a request using its subject, scopes, action, resource, and context, and permits or blocks the operation through policy evaluation. The API never receives the owner’s password or session. section 11.2.1 section 11.2.4
Figure 11.8 Using an OAuth token with Cedar. The client (BI Explorer or Task App) includes an access token in its API request. The API gateway validates the token and then creates a PARC request for Cedar. The request proceeds to the Customer Collaboration API and returns data only if Cedar grants permission.
Follow the boundary flow from bearer-token presentation through gateway validation and policy evaluation to the protected API. section 11.2.4
For integrations, a credential can represent an application rather than a person. Detailed policy can then constrain that integration to its tenant-owned and installed workspaces, while requiring user attribution for write operations. This preserves a usable audit and control point without treating possession of the credential as blanket permission. section 11.2.4 section 11.4
