Keep the entire issued string unchanged
03Generation and later authentication use the entire URI, character for character and case sensitively. Ordinary URI normalization does not justify changing an authentication token.
Alternative attempt: secret-token:demo%2fKey differs in one hex-letter case. It is valid syntax, but differs from this issued credential and fails the exact-identity check.
Source for this drawing: RFC 8959 · Read RFC section 2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The entire URI MUST be used without changes both when generated and when presented for authentication. Keep the scheme, colon and token exactly as issued.
- The entire URI MUST be used without changes both when generated and when presented for authentication. Keep the scheme, colon and token exactly as issued.
- For the issued fixture secret-token:demo%2FKey, stripping the scheme, percent-decoding %2F or changing letter/hex case changes authentication identity.
- ABNF scheme literals can match without regard to case, but accepting scheme syntax does not authorize normalizing an already-issued token.
- The illustrated equality gate checks only this RFC's unchanged-string requirement. An application still needs its own credential validation, expiry, authorization and suitable protected transport; equality alone is not access approval.
RFC8959 §2 requires unchanged, case-sensitive use. This is a bounded comparison of public fixtures, not a production authentication service or an HTTP Authorization serializer.
Read the RFC section ↗