A Token Requestor is the party that initiates tokenization by asking a Token Service Provider to issue a payment token for a specific account and use case. It is usually the customer-facing application, such as a wallet, issuer app, or merchant checkout flow, that presents tokenized payments to the user.
Expanded Definition
A Token Requestor is the application or service that starts the payment tokenisation flow by asking a Token Service Provider to issue a token for a specific account and use case. In practice, this role is usually held by the wallet, issuer app, merchant checkout experience, or another customer-facing payment surface that needs to present tokenised payments without exposing the underlying account number. In payment architecture, the Token Requestor is not the token issuer and does not mint the token itself; it supplies the request context, user or device signal, and intended domain of use.
Definitions vary slightly across vendors and payment networks, but the operational distinction is consistent: the Token Requestor is the system that initiates token lifecycle actions on behalf of the user or merchant flow. That makes it part of the trust boundary around authorisation, device binding, and token domain controls. For a broader risk lens on how token and secret exposure becomes operationally visible, see the Guide to the Secret Sprawl Challenge and NIST’s NIST Cybersecurity Framework 2.0.
The most common misapplication is treating the Token Requestor as a passive transport component, which occurs when teams ignore its authentication, approval, and scope boundaries.
Examples and Use Cases
Implementing Token Requestor controls rigorously often introduces integration and lifecycle overhead, requiring organisations to weigh smoother payment experiences against tighter request validation and auditability.
- A mobile wallet requests a network token when a card is added, then reuses that token for low-friction checkout without revealing the PAN.
- An issuer app acts as the Token Requestor when it provisions a device-bound token after strong customer authentication.
- A merchant checkout flow asks for a token to support recurring payments while constraining the token to that merchant and channel.
- A payment orchestration layer requests tokens for multiple downstream experiences, making request provenance and scope enforcement critical.
- A compromised checkout integration becomes dangerous if it can request tokens outside the intended use case or device context.
Token request flows are only safe when the requestor identity, device posture, and domain restrictions are validated end to end. That matters in real incidents such as the Salesloft OAuth token breach and the JetBrains GitHub plugin token exposure, where token misuse followed weak control over issuance and access context.
Why It Matters in NHI Security
For NHI security, the Token Requestor is significant because it represents a non-human initiation point for credential creation and therefore a potential source of privilege expansion. If the requestor is overtrusted, poorly authenticated, or allowed to request tokens beyond its intended domain, token sprawl and downstream misuse can follow. NHIMG research shows that 44% of NHI tokens are exposed in the wild, sent or stored in collaboration platforms, tickets, pages, and commits, which underscores how quickly token-related workflows can drift outside controlled systems when governance is weak.
This term matters especially in environments where payment flows intersect with app-to-app trust, API automation, and embedded customer journeys. A weak Token Requestor can become the entry point for replay, fraudulent provisioning, or unauthorized token lifecycle actions, even when the underlying token service is well designed. That is why practitioners should treat requestor identity, authorization scope, and audit logging as first-class controls rather than implementation details.
Organisations typically encounter token abuse only after suspicious transaction behaviour or account compromise is investigated, at which point the Token Requestor 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 CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Token requestor trust and token handling connect to secret and token exposure risks. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access applies to systems that initiate token issuance and use. |
| NIST SP 800-63 | Digital identity assurance informs how strongly a requestor and user context are verified. |
Limit token requestor permissions and review access paths so only intended flows can request tokens.
