Possession conveys the token’s use capability
RFC 6750 defines bearer use by the absence of an extra key-possession proof, not by appearance. A token may be opaque or self-contained; being signed or JWT-shaped does not itself change bearer use.
The value is therefore sensitive. Copying an effective token can permit its use without changing its signed contents. Protection against alteration differs from protection against use of a copied value.
Credential placement affects exposure
Bearer requests commonly carry the token in the Authorization header over a protected connection. Transport encryption does not govern endpoint logging, storage or forwarding to an unintended recipient.
The original specification documented but discouraged query-parameter transport; RFC 9700 explicitly prohibits passing access tokens that way. HTTPS does not prevent a token-bearing URL from entering local history or logs.
Use restrictions differ from sender constraints
A resource server still checks validity, intended recipient, resource and action. Narrow scope and short lifetime limit exposure without changing a copyable token into a sender-bound credential.
OAuth practice recommends sender constraints such as mutual TLS or DPoP, adding proof of a bound key beyond possession of the value. An unverified device-name field does not supply that guarantee.
References: [3]