exi
Registry Context
An optional token introspection response member that gives the token's remaining lifetime in seconds, measured from when the resource server first sees the token.
Technical Summary
The `exi` OAuth Token Introspection Response parameter is the `expires_in` claim associated with the access token. It supports expiration handling by resource servers that cannot reliably synchronize their clocks.
When Used
Used in ACE introspection responses when token expiration must be expressed relative to the resource server's first observation of the token rather than as an absolute timestamp.
Normative Requirements
Authorization servers
RFC 9200 - Section 5.10.3
Add a `cti` claim, or a `jti` claim for JWTs, to the access token..
Condition: When creating a token containing an `exi` claim.
When creating the token, the AS MUST add a `cti` claim (or `jti` for JWTs) to the access token.
RFC 9200 - Section 5.10.3
Create the token identifier as the binary representation of the resource-server identifier concatenated with a sequence number for `exi` tokens issued to that resource server..
Condition: When creating the identifier for a token containing an `exi` claim.
The value of this claim MUST be created as the binary representation of the concatenation of the identifier of the RS with a sequence number.
RFC 9200 - Section 5.9.2
Encode a successful introspection response as a CBOR map..
Condition: When CoAP is used.
If CoAP is used, this MUST be encoded as a CBOR map.
RFC 9200 - Section 5.9.2
Include the `exi` parameter in an introspection response..
This parameter is OPTIONAL.
Resource servers
RFC 9200 - Section 5.10.3
Store the highest sequence number seen for an expired token containing `exi` and treat tokens with lower sequence numbers as expired..
Condition: When processing tokens containing an `exi` claim.
The RS MUST store the highest sequence number of an expired token containing the `exi` claim that it has seen and treat tokens with lower sequence numbers as expired.
RFC 9200 - Section 5.10.3
Send an error response equivalent to CoAP 4.01 Unauthorized and terminate processing of a long-running request..
Condition: When the token authorizing that request expires.
The RS MUST send an error response with the response code equivalent to the CoAP code 4.01 (Unauthorized) ... and then terminate processing.
Registry applicant and designated expert
RFC 7662 - Section 3.1.1
Ensure that a name matching a registered JWT claim has a comparable definition and semantics..
Condition: When the proposed response name matches a name in the JSON Web Token Claims registry.
Names that match claims registered in the "JSON Web Token Claims" registry ... SHOULD have comparable definitions and semantics.
Registry designated expert
RFC 7662 - Section 3.1.1
Accept a proposed name that differs from an existing registered name only by case..
Condition: When reviewing a proposed registry name.
Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.
Specification author
RFC 7662 - Section 2.2
Register response names in the OAuth Token Introspection Response registry..
Condition: When a response name is intended for use across domains.
Response names intended to be used across domains MUST be registered in the "OAuth Token Introspection Response" registry.
Validation Guidance
Treat `exi` as case-sensitive. During registry review, flag proposed names that differ from existing names only by case.
For a response name intended for cross-domain use, verify that it is registered in the OAuth Token Introspection Response registry.
Verify that `exi` has semantics comparable to the registered JWT claim of the same name.
Allow `exi` to be absent from an introspection response.
Interpret `exi` as a lifetime in seconds measured from when the resource server first sees the token.
When CoAP is used, require the successful introspection response to be encoded as a CBOR map.
For tokens using the `exi` expiration mechanism, verify the required `cti` or JWT `jti` identifier and sequence-number construction.
Verify that the resource server tracks expired sequence numbers and rejects lower sequence numbers as expired.
Security Notes
RFC 9200 - Section 6.6
A malicious client can delay presenting a token containing `exi`, thereby prolonging its effective lifetime because the lifetime begins when the resource server first sees it.
RFC 9200 - Section 6.6
If a resource server loses state, such as after an unscheduled reboot, it may lose the counters used to track tokens containing `exi`; regularly persisting those counters can mitigate this risk.
Reference
Details
- Entry Id
exi- Name
exi- Description
"Expires in". Lifetime of the token in seconds from the time the RS first sees it. Used to implement a weaker form of token expiration for devices that cannot synchronize their internal clocks.- Change Controller
IETF- Reference
RFC9200 - Section 5.9.2