Control objective
The resource parameter lets a client identify the protected resource for which it wants a token. The authorization server can use it to select audience and limit token authority. It is not a resource permission by itself.
Request and validation
The client sends an absolute resource identifier in the authorization or token request as the selected profile permits. The authorization server validates it and issues a token for the approved resource. The resource server verifies that it is the intended audience.
Scope relationship
Resource identifies the target service. Scope describes delegated authority as the authorization design defines it. The resource server still authorizes the named object and action. Keep tokens for different resources distinct.
Failure and residual risk
An authorization server can ignore or broaden the requested resource. A client can request several resources. A resource server can fail to verify audience. A token for one API can then cross into another context.
Pomerium boundary
Pomerium behavior depends on the documented token and identity flow selected by the deployment. Operators must verify whether a resource parameter is supported and how the resulting audience is validated. Route authorization does not replace resource-server checks.
Evaluation checklist
- Which exact resource identifier does the client request?
- How does the authorization server validate and approve it?
- Which token claim binds the result to the resource server?
- Does the resource server reject a token for another audience?
- Which object and action permission remains after resource selection?
