Who enforces resource access?
Cloud API
For some auth flows, resource access is enforced by Cloud API. For these auth flows, the call either includes a resource access ID, or includes information that can be mapped to a resource access ID. This ID determines which specific instances of a resource the caller can access. The following Cloud API auth flows support this:
- Internal user
- External user
- Service with internal user context
- Service with external user context
- Service with service account mapping
The caller application itself
For other auth flows, Cloud API provides unrestricted resource access. This is done under the assumption that resource access will be enforced by the caller application itself. In this case, calls do not include resource access IDs. The caller is given access to any specific resource, provided they have sufficient endpoint access. The following Cloud API auth flows support this:
- Standalone service
Summary of behaviors
The following table summarizes these behaviors.
| Internal User | External User | Standalone service | Service with Internal User Context | Service with External User Context | Service with Service Account Mapping | |
|---|---|---|---|---|---|---|
| Does Cloud API enforce resource access? | Yes | Yes |
No (The service is expected to enforce it.) |
Yes | Yes | Yes |
For a summary of all the issues to consider in a single table, see Summary of the issues to consider.