Once a user or workload has authenticated, the token it receives becomes the credential that matters, and whoever holds it is trusted. D3-TBA Token-based Authentication is the MITRE D3FEND countermeasure for that exchange: D3FEND defines it as "an authentication protocol where users verify their identity in exchange for a unique access token", after which they can reach the resource "for the life of the token without having to re-enter their credentials." It sits in the Harden tactic as a child of Agent Authentication and, in D3FEND's model, uses the Access Token artefact. This card explains what D3-TBA hardens, which ATT&CK techniques D3FEND relates it to, where it is implemented, how to verify it, and where it stops helping. It is written for identity engineers, API owners and detection teams who issue or accept tokens and want a precise view of the control's reach.
Key takeaways
- D3-TBA moves risk from the password to the token. Fewer password prompts mean fewer chances to steal a password, but every issued token is now a credential in its own right.
- D3FEND's own considerations name the core limit. Its knowledge base calls the result a "bearer token": access is granted to whoever holds it, so the hardening comes from lifetime, audience, scope and binding, not from the token alone.
- The ATT&CK mapping is inferred and broad. D3FEND relates D3-TBA to ATT&CK through the Access Token and User Account artefacts. Treat the list as "relevant to", not "blocked by".
- "Access token" means two different things. D3FEND's artefact covers both OAuth-style web and API tokens and operating system access tokens, which is why Windows token manipulation appears in the mapping. Plan controls for each separately.
- Verify with replay tests and token telemetry. Check that expired, revoked, wrong-audience and replayed tokens are refused, and measure token lifetimes and revocation speed.
D3-TBA at a glance
| Field | D3-TBA Token-based Authentication |
|---|---|
| D3FEND ID | D3-TBA |
| Tactic | Harden |
| Parent technique | Agent Authentication (siblings: Biometric Authentication, Certificate-based Authentication, Multi-factor Authentication, Password Authentication) |
| Digital artefacts | Uses Access Token; the parent Agent Authentication strengthens User Account |
| What it changes | After one primary authentication, an issuer hands the client a token that it presents on later requests, instead of resending a password |
| D3FEND reference | Entrust, "What is Token Based Authentication" (internet article) |
| Typical implementation points | OAuth 2.0 authorisation servers and OpenID Connect providers, API gateways and resource servers, SAML and session cookie issuers, Kerberos, operating system logon sessions |
| Main limitation | Bearer tokens can be replayed by anyone who obtains them during their lifetime |
| Hardening partner | D3-TB Token Binding, which ties a token to a key the client holds |
How it works
D3FEND's knowledge base article describes a sequence: the user authenticates (typically with a password or security question), an authorisation server validates that authentication and issues an access token, and the client presents the token to an API or resource server until the token's lifecycle ends through logout, application exit or a time-out. The reference D3FEND cites adds that JSON Web Tokens (RFC 7519) are a common format, that their payload is easily decoded so should not carry sensitive data, and that expiry and revocation have to be designed in.
The defensive value is real but conditional. It comes from three properties, all of which the issuer controls:
- Exposure reduction: the long-lived secret (a password or client secret) is presented once to one issuer, not to every service on every request.
- Limited lifetime and scope: RFC 6750 says bearer token lifetime "MUST" be limited and that issuers "SHOULD" issue short-lived tokens, one hour or less, and "SHOULD" restrict the audience. RFC 9700 (OAuth 2.0 Security Best Current Practice, BCP 240) adds that access tokens "SHOULD be audience-restricted to a specific resource server" and that privileges "SHOULD be restricted to the minimum required".
- Central control: the issuer can refuse to refresh, revoke, or change policy without touching each resource server's password store.
RFC 6750 defines a bearer token as "A security token with the property that any party in possession of the token (a "bearer") can use the token in any way", without proof of possession of key material. That is the gap D3FEND's considerations point to, and why RFC 9700 says authorisation and resource servers "SHOULD use mechanisms for sender-constraining access tokens", naming mutual TLS (RFC 8705) and DPoP (RFC 9449). For the token format itself, see the JWT Security Guide; for the OAuth baseline, see the OAuth 2.0 Security Best Current Practice (RFC 9700) Guide.
Two kinds of access token
D3FEND uses one Access Token artefact for two different objects, and the ATT&CK mapping mixes them:
| Aspect | Web and API tokens (OAuth, OIDC, session cookies) | Operating system access tokens (Windows) |
|---|---|---|
| What it is | A credential a client presents to a remote resource server | Microsoft: "an object that describes the security context of a process or thread", created at logon and copied to every process the user starts |
| Contents | Issuer, subject, audience, scopes, expiry, optional key confirmation (cnf) | User and group SIDs, logon SID, privileges, default DACL, primary or impersonation type |
| Main abuse | Theft and replay from another client (T1528, T1550.001) | Duplication and impersonation on the host (T1134.001 to T1134.003) |
| Hardening levers | Short lifetime, audience restriction, least scope, sender constraint, revocation | Least privilege for accounts and services, restricting who holds token-related privileges, endpoint detection of token API misuse |
For the host-side techniques, see the MITRE ATT&CK T1134 Access Token Manipulation.
ATT&CK techniques D3FEND relates to D3-TBA
Relationship type: inferred only. D3FEND marks these mappings as "inferred, experimental" and derives them through shared digital artefacts: D3-TBA uses Access Token, and its parent strengthens User Account, so ATT&CK techniques that act on either artefact are related to it. D3FEND lists no direct mapping and no ATT&CK mitigation for D3-TBA (checked November 2026). Each ID was checked against ATT&CK v20. The last column is NHI Mgmt Group's assessment, not part of D3FEND.
| ATT&CK ID | Technique | Shared artefact | What D3-TBA changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1528 | Steal Application Access Token | Access Token | Partial: short lifetimes and narrow scope shrink the window and blast radius; only binding stops replay |
| T1550.001 | Use Alternate Authentication Material: Application Access Token | Access Token | Partial: audience restriction stops reuse at other services; bearer reuse at the intended service still works |
| T1134.001, T1134.002, T1134.003 | Token Impersonation/Theft, Create Process with Token, Make and Impersonate Token | Access Token (operating system) | Minimal: these act on host tokens after logon; host privilege controls matter more |
| T1558.001 | Golden Ticket | Access Token (Kerberos ticket) | Minimal: a forged ticket is issued outside the legitimate token service |
| T1078.001, T1078.002, T1078.003, T1078.004 | Valid Accounts: Default, Domain, Local, Cloud Accounts | User Account | Partial: fewer password presentations, but the primary login still needs strong authentication |
| T1098.002, T1098.003 | Additional Email Delegate Permissions, Additional Cloud Roles | User Account | Indirect: least-scope tokens limit what a stolen token can change |
| T1548.005 | Temporary Elevated Cloud Access | User Account | Partial: elevation tied to short-lived, freshly issued tokens limits reuse |
| T1136.001, T1136.002, T1136.003 | Create Account: Local, Domain, Cloud Account | User Account | Indirect |
| T1087.001, T1087.002, T1087.004 | Account Discovery: Local, Domain, Cloud Account | User Account | Indirect |
| T1531 | Account Access Removal | User Account | Indirect: protects the administrative tokens used to lock others out |
For the token theft and reuse techniques where tokens matter most, see the MITRE ATT&CK T1528 Steal Application Access Token Guide and the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide.
Where it is implemented
| Enforcement point | What to configure | Typical gap |
|---|---|---|
| Authorisation server or identity provider | Access token lifetime, refresh token rotation or binding, audience (aud) per resource, minimal scopes, signing key rotation | One long lifetime applied to every client, including scripts and agents |
| Resource server and API gateway | Validate signature, issuer, audience, expiry and scope on every request; reject tokens in URL query strings | Gateways that check the signature but not the audience |
| Token introspection and revocation endpoints | Introspection for opaque or high-value tokens; revocation wired to incident response | Self-contained JWTs that stay valid until expiry after revocation |
| Browser applications | Back-end-for-front-end pattern, HttpOnly session cookies, no tokens in local storage | Tokens readable by any script on the page |
| Machine and agent clients | Client credentials with private_key_jwt or mTLS, workload federation instead of static API keys | Long-lived personal access tokens used as service credentials |
| Operating systems | Restrict token-related privileges and administrative rights; monitor token duplication APIs | Service accounts holding broad privileges they never use |
RFC 9700 adds rules that matter at these points: public clients' refresh tokens "MUST be sender-constrained or use refresh token rotation", clients "MUST NOT pass access tokens in a URI query parameter", and resource servers "MUST treat access tokens like other sensitive secrets". See the OAuth Refresh Token Rotation and Expiry Guide and the OAuth for Browser-Based Applications and the BFF Pattern Guide.
Where identity and NHIs fit
Most tokens in a modern estate are held by software: CI/CD jobs, integrations, service principals and AI agents. These are exactly the tokens that tend to be long-lived, broadly scoped and stored in files or variables. The Sourcegraph breach shows the pattern: a site-admin access token committed to public code sat exposed for 47 days before an attacker used it to create and promote an admin account. Token-based authentication helped nobody there because the token was long-lived and over-privileged. For machine clients, see the Machine-to-Machine OAuth (Client Credentials) Guide.
Implementation steps
- Inventory issuers and token types. List each identity provider, authorisation server and API platform, the token formats it issues (JWT, opaque, cookie, personal access token), lifetimes, and which clients hold them, human and non-human.
- Set lifetime and audience by risk. Use short access token lifetimes (RFC 6750 suggests one hour or less as a default) and an audience per resource server. Example values for your own policy might be minutes for privileged APIs and hours for low-risk reads; these are examples, not standards.
- Reduce scope. Map each client to the minimum scopes it uses; remove wildcard and administrative scopes from routine clients. See the OAuth Scope Design Guide.
- Enforce validation at every resource server. Check signature, issuer, audience, expiry and scope; test with tokens that fail each check one at a time.
- Wire revocation into response. Make sure a token or session can be revoked centrally and that resource servers honour it (introspection, short lifetime or event signals). Pair with D3-ANCI Authentication Cache Invalidation.
- Add binding where the platform allows. Move high-value clients to sender-constrained tokens with mTLS or DPoP. See D3-TB Token Binding.
- Roll out in stages with rollback. Shorter lifetimes and stricter audience checks break clients that cache tokens or share them across services. Apply changes per client or application group, watch error rates, and keep the previous policy ready to restore.
How to verify it works
- Negative token tests: present an expired token, a token for another audience, a token with a missing scope, a token with an altered signature, and a token passed in a query string. Each should fail with an authentication error.
- Revocation test: revoke a test token or session and time how long resource servers keep accepting it.
- Replay test: in an authorised test, replay a valid token from a different client and network. With bearer tokens it will succeed; record that as the residual risk, or as a failure if the client is meant to be sender-constrained.
- Log review: confirm issuers log token issuance with client ID, scopes and lifetime, and resource servers log token identifier (jti or hash, never the token itself), client and outcome.
| Metric | What it shows | Target direction |
|---|---|---|
| Share of tokens issued with lifetime above your policy maximum | Lifetime drift | Falling to zero, exceptions recorded |
| Share of resource servers enforcing audience checks | Cross-service replay exposure | Rising to 100% |
| Median time from revocation to last accepted use | Real revocation speed | Below the access token lifetime |
| Long-lived non-human tokens without an owner or expiry | Machine token debt | Falling |
| Same token identifier seen from two clients or networks | Possible replay | Each event triaged |
| Share of high-value clients using sender-constrained tokens | Progress from bearer to bound tokens | Rising |
Session-side analytics help with the replay metric; see D3-WSAA Web Session Activity Analysis and How to detect use of a stolen OAuth refresh token.
Limits, bypasses and failure patterns
- Bearer replay: a token copied from a browser, log file, proxy or infostealer works from anywhere until it expires. In CitrixBleed 2023, session cookies read from appliance memory gave attackers authenticated sessions, and patching did not invalidate cookies already taken; sessions had to be terminated.
- Long-lived tokens used as passwords: personal access tokens and API keys with no expiry turn token-based authentication back into a static secret.
- Missing audience checks: a token issued for one API is accepted by another because only the signature is validated.
- Revocation that does not reach resource servers: self-contained tokens stay valid after an account is disabled unless lifetimes are short or servers check status.
- Tokens in logs and URLs: query-string tokens and verbose logging copy credentials into places with weaker access control. See the JWT and Session Tokens in Code and Logs Guide.
- Weak primary authentication: the token is only as trustworthy as the login that produced it, which is why D3-TBA is usually paired with D3-MFA Multi-factor Authentication.
Framework mapping
| Framework | Reference | Relationship to D3-TBA |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2, IA-5, SC-23 | Identification and authentication, authenticator management, session authenticity |
| NIST SP 800-53 Rev 5 | IA-9 | Service identification and authentication, for machine clients |
| NIST CSF 2.0 | PR.AA-03 | Users, services and hardware are authenticated |
| IETF | RFC 6750, RFC 9700 | Bearer token usage rules and the OAuth security best current practice |
| MITRE ATT&CK | T1528, T1550.001, T1134 | Inferred via the Access Token artefact (see table above) |
The framework rows are NHI Mgmt Group's mapping, not part of D3FEND.
Related countermeasures
- Siblings under Agent Authentication: D3-MFA Multi-factor Authentication hardens the login that issues the token; D3-CBAN Certificate-based Authentication suits workloads.
- Credential hardening: D3-TB Token Binding removes the bearer property.
- Eviction and deception: D3-CR Credential Revocation and D3-DST Decoy Session Token cover the period after a token is stolen.
Practitioner checklist
- Inventory every token issuer, token type, lifetime and holder, including non-human clients.
- Set short access token lifetimes and an audience per resource server.
- Remove broad scopes from routine clients and review scopes on each integration change.
- Validate signature, issuer, audience, expiry and scope at every resource server.
- Rotate or bind refresh tokens; never put access tokens in URLs or logs.
- Test revocation end to end and measure how long revoked tokens keep working.
- Replace long-lived personal access tokens used by automation with federated or short-lived credentials.
- Move high-value clients to sender-constrained tokens (mTLS or DPoP).
Standards and references
- MITRE D3FEND: Token-based Authentication (D3-TBA)
- IETF: RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- IETF: RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
- IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
- Microsoft: Access Tokens (Win32 authorization)
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- Entrust: What is Token Based Authentication
Related NHI Mgmt Group resources: MITRE D3FEND Guide · API Keys vs OAuth Tokens Guide · OAuth Token Introspection and Revocation Guide · DPoP Guide · OAuth Token Theft Incident Playbook