A resource indicator is a request-time signal in OAuth that tells the authorization server which resource server the token is meant for. In practice, it helps constrain the resulting token audience so access is tied to one API or logical service instead of being broadly reusable.
Expanded Definition
A resource indicator is the request-time value that tells an authorization server which API or resource server should receive the resulting access token. In OAuth deployments, it narrows token audience so the credential is bound to a specific service instead of becoming broadly reusable across unrelated systems.
That distinction matters because audience scoping is a control boundary, not just a naming convention. The term is defined in OAuth guidance, but implementations vary: some platforms use explicit resource parameters, others rely on audience claims, and some still mix both patterns. For that reason, operational guidance should be read alongside the relevant NIST Cybersecurity Framework 2.0 principles for access control and identity governance. In NHI environments, a resource indicator is especially important when the same agent, service account, or automation pipeline calls multiple APIs with different privilege sets.
When used well, it reduces token replay value, limits blast radius, and makes downstream authorization decisions more predictable. The most common misapplication is treating the resource indicator as optional metadata, which occurs when teams issue generic tokens and expect each resource server to sort out audience mismatches later.
Examples and Use Cases
Implementing resource indicators rigorously often introduces extra client configuration and token issuance complexity, requiring organisations to weigh tighter audience control against integration overhead.
- A build agent requests a token for a secrets API and separately requests another token for a deployment API, so each token carries only the audience needed for that task.
- An internal gateway forwards an access request to the correct backend by validating the token audience before proxying traffic to the target service.
- An engineering team replaces a shared bearer token with per-service audience scoping after reviewing lessons from the ASP.NET machine keys RCE attack, where weak credential boundaries amplified impact.
- A multi-tenant SaaS platform issues distinct tokens for customer-specific resource servers so one tenant’s automation cannot reuse another tenant’s token.
- A platform team aligns its token design with NIST Cybersecurity Framework 2.0 access controls to ensure audience restrictions are enforceable and auditable.
In practice, resource indicators are most valuable when the environment has many APIs, multiple trust zones, or autonomous agents that can reach more than one backend. They help security teams express intent at issuance time rather than relying on every downstream service to infer it correctly.
Why It Matters in NHI Security
Resource indicators are central to NHI security because non-human credentials are often overpowered, long-lived, and reused across service boundaries. When a token is not audience-scoped, a compromise in one workflow can spill into unrelated APIs, turning a single secret into broad lateral movement. That is precisely the kind of exposure NHI governance is meant to prevent, especially when ASP.NET machine keys RCE attack style failures show how one weak control can cascade into full application compromise.
NHIMG research shows that Only 5.7% of organisations have full visibility into their service accounts. That gap matters because audience mistakes are easy to miss when service identities are already hard to inventory. Resource indicators help reduce hidden reuse, improve token traceability, and support least privilege across automation, agents, and backend services. They also reinforce Zero Trust expectations by forcing each request to prove the intended destination, not just the caller identity.
Organisations typically encounter the operational importance of resource indicators only after a token is replayed against the wrong API or a service-to-service breach exposes multiple backends, at which point the control becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers token misuse, audience scoping, and secret-bound NHI access controls. |
| NIST Zero Trust (SP 800-207) | 5.2 | Zero Trust requires explicit, per-request access decisions for each protected resource. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is reinforced when tokens are limited to the intended resource. |
Limit token audience to the minimum required service and review service-to-service permissions regularly.
