RFC 7662

OAuth 2.0 Token Introspection

📅 published October 2015, from ietf

Abstract ✨

Okay bestie, let's start with the paperwork 📄💅 This is RFC 7662: OAuth 2.0 Token Introspection, an IETF document by J. Richer, Ed. (the "Ed." means editor 🎀). It's on the Standards Track, it was published in October 2015, and its ISSN is 2070-1721. The title block doesn't say it obsoletes or updates any other documents, so no drama there 😌

The abstract is basically the elevator pitch 🛗 This spec gives a protected resource a way to ask an OAuth 2.0 authorization server whether a token is currently active and to get meta-information about that token. OAuth 2.0 setups can use this method to pass the token's authorization context from the authorization server over to the protected resource 🦋

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7662.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
  1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Introspection Endpoint  . . . . . . . . . . . . . . . . . . .   3
  2.1.  Introspection Request . . . . . . . . . . . . . . . . . .   4
  2.2.  Introspection Response  . . . . . . . . . . . . . . . . .   6
  2.3.  Error Response  . . . . . . . . . . . . . . . . . . . . .   8
3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
  3.1.  OAuth Token Introspection Response Registry . . . . . . .   9
    3.1.1.  Registration Template . . . . . . . . . . . . . . . .  10
    3.1.2.  Initial Registry Contents . . . . . . . . . . . . . .  10
4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  14
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
  6.2.  Informative References  . . . . . . . . . . . . . . . . .  16
Appendix A.  Use with Proof-of-Possession Tokens  . . . . . . . .  17
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction 🦋

Okay so in OAuth 2.0 [RFC6749], tokens are opaque to clients 🙈 That means the client doesn't need to know anything about what's inside the token or how it's structured, if there's anything in there at all. But there's still a ton of metadata that can be attached to a token, like whether it's currently valid, which scopes were approved, and info about the situation it was issued in. This stuff is super important for protected resources when they're making authorization decisions based on the tokens they're handed. OAuth 2.0 doesn't define a protocol for the resource server to learn this metadata from the authorization server, so people came up with different workarounds to bridge that gap. Some use structured token formats like JWT [RFC7519], and others use proprietary inter-service mechanisms (like shared databases and protected enterprise service buses) to pass the info around 💅

This spec is the protocol that lets an authorized protected resource ask the authorization server for the metadata about a given token that an OAuth 2.0 client presented to it. That metadata includes whether the token is currently active (or whether it has expired or been revoked), what access rights it carries (usually expressed as OAuth 2.0 scopes), and the authorization context it was granted in, including who authorized it and which client it was issued to ✨ Token introspection lets the protected resource ask all of this whether or not the info is actually inside the token itself, so it can be used alongside structured token values or completely on its own 🫶 And a protected resource can also use this mechanism to introspect a token within a particular authorization decision context, so it can figure out the relevant metadata and make that decision properly 👑

1.1. Notational Conventions

The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [RFC2119].

Unless otherwise noted, all the protocol parameter names and values are case sensitive. 🧐 So Token and token are not the same thing, bestie!

1.2. Terminology

This section defines the terminology used by this specification. This section is a normative portion of this specification, imposing requirements upon implementations. 📜

This specification uses the terms "access token", "authorization endpoint", "authorization grant", "authorization server", "client", "client identifier", "protected resource", "refresh token", "resource owner", "resource server", and "token endpoint" defined by OAuth 2.0 [RFC6749], and the terms "claim names" and "claim values" defined by JSON Web Token (JWT) [RFC7519].

This specification defines the following terms:

Token Introspection The act of inquiring about the current state of an OAuth 2.0 token through use of the network protocol defined in this document. 🔍

Introspection Endpoint The OAuth 2.0 endpoint through which the token introspection operation is accomplished. 🎯

2. Introspection Endpoint 🔥

The introspection endpoint is an OAuth 2.0 endpoint. It takes a parameter that represents an OAuth 2.0 token and returns a JSON [RFC7159] document describing the meta information around that token, including whether the token is currently active 💖 What counts as an active token depends on the authorization server, but it's commonly a token that this authorization server issued, that isn't expired, that hasn't been revoked, and that is valid for use at the protected resource making the introspection call 🍓

The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4. How the protected resource finds the location of the introspection endpoint is outside the scope of this specification. 🔒

2.1. Introspection Request 💌

The protected resource calls the introspection endpoint with an HTTP POST [RFC7231] request, sending parameters as "application/x-www-form-urlencoded" data as defined in [W3C.REC-html5-20141028]. The protected resource sends a parameter representing the token, along with optional parameters that give extra context the protected resource knows about, to help the authorization server with its response 🎀

token REQUIRED. The string value of the token. For access tokens, this is the "access_token" value returned from the token endpoint defined in OAuth 2.0 [RFC6749], Section 5.1. For refresh tokens, this is the "refresh_token" value returned from the token endpoint as defined in OAuth 2.0 [RFC6749], Section 5.1. Other token types are outside the scope of this specification. 🌈

token_type_hint OPTIONAL. A hint about the type of the token submitted for introspection. The protected resource MAY pass this parameter to help the authorization server optimize the token lookup. If the server is unable to locate the token using the given hint, it MUST extend its search across all of its supported token types. An authorization server MAY ignore this parameter, particularly if it is able to detect the token type automatically. Values for this field are defined in the "OAuth Token Type Hints" registry defined in OAuth Token Revocation [RFC7009]. 🧠

The introspection endpoint MAY accept other OPTIONAL parameters to provide further context to the query. For instance, an authorization server may desire to know the IP address of the client accessing the protected resource to determine if the correct client is likely to be presenting the token 🕵️‍♀️ The definition of this or any other parameters is outside the scope of this specification, and is to be defined by service documentation or extensions to this specification. If the authorization server is unable to determine the state of the token without additional information, it SHOULD return an introspection response indicating the token is not active as described in Section 2.2. 🙅‍♀️

To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750]. The methods of managing and validating these authentication credentials are out of scope of this specification. 🛡️

Here's an example of a protected resource calling the token introspection endpoint to ask about an OAuth 2.0 bearer token. The protected resource is using a separate OAuth 2.0 bearer token to authorize this call 🦋

The following is a non-normative example request:

POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer 23410913-abewfq.123483

token=2YotnFZFEjr1zCsicMWpAA

In this example, the protected resource uses a client identifier and client secret to authenticate itself to the introspection endpoint. The protected resource also sends a token type hint indicating that it is inquiring about an access token ✨

The following is a non-normative example request:

POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

token=mF_9.B5f-4.1JqM&token_type_hint=access_token

2.2. Introspection Response

okay so the server answers back with a JSON object [RFC7159] in application/json format, and it has these top-level members 💅

active REQUIRED. This is a boolean that tells you whether the token you sent is currently active 🦋. What "active" actually means depends on the authorization server and what it keeps track of for its tokens. Generally, a true here means the token was issued by this authorization server, the resource owner hasn't revoked it, and it's inside its validity window (for example, after its issuance time and before its expiration time). See Section 4 for info on how to do those checks.

scope OPTIONAL. A JSON string holding a space-separated list of the scopes attached to this token, in the format from Section 3.3 of OAuth 2.0 [RFC6749] 🎀

client_id OPTIONAL. The client identifier for the OAuth 2.0 client that asked for this token 🌸

username OPTIONAL. A human-readable identifier for the resource owner who authorized this token 🧚

token_type OPTIONAL. The type of the token, as defined in Section 5.1 of OAuth 2.0 [RFC6749] ✨

exp OPTIONAL. An integer timestamp counting the seconds since January 1 1970 UTC, showing when this token will expire, as defined in JWT [RFC7519] ⏳

iat OPTIONAL. An integer timestamp (same seconds-since-1970 UTC deal) showing when this token was originally issued, as defined in JWT [RFC7519] 🌈

nbf OPTIONAL. An integer timestamp (yep, same format) showing when this token is not to be used before, as defined in JWT [RFC7519] 🙈

sub OPTIONAL. The subject of the token, as defined in JWT [RFC7519]. Usually this is a machine-readable identifier for the resource owner who authorized the token 🫶

aud OPTIONAL. A service-specific string identifier, or a list of them, representing the intended audience for this token, as defined in JWT [RFC7519] 👑

iss OPTIONAL. A string naming the issuer of this token, as defined in JWT [RFC7519] 🔥

jti OPTIONAL. A string identifier for the token, as defined in JWT [RFC7519] 💜

Specific implementations MAY extend this structure with their own service-specific response names as top-level members of the JSON object. Response names meant to be used across domains MUST be registered in the "OAuth Token Introspection Response" registry defined in Section 3.1. Extensibility with registration, very organized 🍓

The authorization server MAY respond differently to different protected resources making the same request. For example, an authorization server MAY limit which scopes from a given token get returned to each protected resource, so that a protected resource doesn't learn more about the larger network than it needs to run 🌙

The response MAY be cached by the protected resource to improve performance and reduce load on the introspection endpoint. The catch is that it costs you liveness of the information the protected resource uses to make authorization decisions. See Section 4 for more on that trade-off when the response is cached 💀

For example, the following response contains a set of information about an active token:

The following is a non-normative example response:

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
   "active": true,
   "client_id": "l238j323ds-23ij4",
   "username": "jdoe",
   "scope": "read write dolphin",
   "sub": "Z5O3upPC88QrAjx00dis",
   "aud": "https://protected.example.net/resource",
   "iss": "https://server.example.com/",
   "exp": 1419356238,
   "iat": 1419350238,
   "extension_field": "twenty-seven"
  }

If the introspection call is properly authorized but the token is not active, does not exist on this server, or the protected resource is not allowed to introspect this particular token, then the authorization server MUST return an introspection response with the active field set to false. Also, to avoid giving a third party too much info about the authorization server's state, the authorization server SHOULD NOT include any additional information about an inactive token, including why the token is inactive. Keep it lowkey 🤫

The following is a non-normative example response for a token that has been revoked or is otherwise invalid:

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
   "active": false
  }

2.3. Error Response

If the protected resource uses OAuth 2.0 client credentials to authenticate to the introspection endpoint and those credentials are invalid, the authorization server responds with an HTTP 401 (Unauthorized), as described in Section 5.2 of OAuth 2.0 [RFC6749] 🚫

If the protected resource uses an OAuth 2.0 bearer token to authorize its call to the introspection endpoint, and that token doesn't have sufficient privileges or is otherwise invalid for this request, the authorization server responds with an HTTP 401 code, as described in Section 3 of OAuth 2.0 Bearer Token Usage [RFC6750] 🙅‍♀️

Note that a properly formed and authorized query for an inactive or otherwise invalid token (or a token the protected resource is not allowed to know about) is not considered an error response by this specification. In these cases, the authorization server MUST instead respond with an introspection response with the active field set to false, as described in Section 2.2 🎀

Not an error! It's just a normal active: false response. Don't panic, bestie 💖

3. IANA Considerations ✨

3.1. OAuth Token Introspection Response Registry

This specification establishes the "OAuth Token Introspection Response" registry 📚

OAuth registration client metadata names and descriptions are registered by Specification Required [RFC5226] after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published 🌸

Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Token Introspection Response name: example") 💌

Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating that decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions for how to make the request successful 🦋

IANA must only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list 🫶

3.1.1. Registration Template

Name: The name requested (e.g., "example"). This name is case sensitive. Names that match other registered names in a case-insensitive manner SHOULD NOT be accepted. Names that match claims registered in the "JSON Web Token Claims" registry established by [RFC7519] SHOULD have comparable definitions and semantics 🔍

Description: A brief description of the metadata value (e.g., "Example description") 📝

Change controller: For Standards Track RFCs, state "IESG". For other documents, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included 📮

Specification document(s): A reference to the document(s) that specify the token endpoint authorization method, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required 🔗

3.1.2. Initial Registry Contents

The initial contents of the "OAuth Token Introspection Response" registry are as follows 🌈

  • Name: "active"
    • Description: Token active status
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).
  • Name: "username"
    • Description: User identifier of the resource owner
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).
  • Name: "client_id"
    • Description: Client identifier of the client
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).
  • Name: "scope"
    • Description: Authorized scopes of the token
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).
  • Name: "token_type"
    • Description: Type of the token
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).
  • Name: "exp"
    • Description: Expiration timestamp of the token
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).
  • Name: "iat"
    • Description: Issuance timestamp of the token
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).
  • Name: "nbf"
    • Description: Timestamp before which the token is not valid
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).
  • Name: "sub"
    • Description: Subject of the token
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).
  • Name: "aud"
    • Description: Audience of the token
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).
  • Name: "iss"
    • Description: Issuer of the token
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).
  • Name: "jti"
    • Description: Unique identifier of the token
    • Change Controller: IESG
    • Specification Document(s): Section 2.2 of RFC 7662 (this document).

4. Security Considerations 🔐

okay bestie, this is the serious bit 😭 there are SO many valid ways to build an OAuth 2.0 system, so there are also lots of ways an authorization server can figure out whether a token is currently "active" ✨. BUT the resource servers doing token introspection are trusting the authorization server to tell them the state of a token, so the authorization server MUST perform all applicable checks against a token's state. These tests include the following:

  • If the token can expire, the authorization server MUST determine whether or not the token has expired. ⏰
  • If the token can be issued before it is able to be used, the authorization server MUST determine whether or not a token's valid period has started yet. 🚦
  • If the token can be revoked after it was issued, the authorization server MUST determine whether or not such a revocation has taken place. 🚫
  • If the token has been signed, the authorization server MUST validate the signature. ✍️
  • If the token can be used only at certain resource servers, the authorization server MUST determine whether or not the token can be used at the resource server making the introspection call. 🎯

If an authorization server skips any applicable check, the resource server could make a wrong security decision based on that response, and that is NOT the vibe 💀. Not every one of these checks will apply to every OAuth 2.0 deployment, though. It's up to the authorization server to decide which checks (and any other checks) apply 💅.

If the introspection endpoint is left unprotected and un-throttled, it could give an attacker a way to poll a bunch of possible token values, fishing for a valid one 🎣. To stop that, the authorization server MUST require authentication of protected resources that need to access the introspection endpoint, and SHOULD require protected resources to be specifically authorized to call the introspection endpoint 🛡️. The details of those authentication credentials are out of scope for this spec, but they could commonly look like any valid client authentication mechanism used with the token endpoint, an OAuth 2.0 access token, or some other HTTP authorization or authentication mechanism 🧚. A single piece of software acting as both a client and a protected resource MAY reuse the same credentials between the token endpoint and the introspection endpoint. Doing that can blur the line between the client and protected resource parts of the software, though, so the authorization server MAY require separate credentials for each mode 🎀.

Since the introspection endpoint takes in OAuth 2.0 tokens as parameters and responds with info used to make authorization decisions, the server MUST support Transport Layer Security (TLS) 1.2 [RFC5246], and MAY support additional transport-layer mechanisms that meet its security requirements 🔒. When using TLS, the client or protected resource MUST perform a TLS/SSL server certificate check, as specified in [RFC6125]. Implementation security considerations can be found in Recommendations for Secure Use of TLS and DTLS [BCP195] 📖.

To keep access token values from leaking into server-side logs through query parameters, an authorization server offering token introspection MAY disallow the use of HTTP GET on the introspection endpoint, and instead require the HTTP POST method to be used at the introspection endpoint 🙈.

To avoid revealing the internal state of the authorization server, an introspection response for an inactive token SHOULD NOT contain any additional claims beyond the required active claim (with its value set to false) 🤫.

Since a protected resource MAY cache the response of the introspection endpoint, designers of an OAuth 2.0 system using this protocol MUST consider the performance and security trade-offs that come with caching security info like this 🧐. A less aggressive cache with a short timeout gives the protected resource more up-to-date info (because it has to query the introspection endpoint more often), but it costs more network traffic and load on the introspection endpoint 📈. A more aggressive cache with a longer duration keeps network traffic and load on the introspection endpoint low, but it risks stale info about the token 🥶. For example, the token may be revoked while the protected resource is still relying on the cached response to make authorization decisions. That opens a window where a revoked token could still be used at the protected resource 😬. So an acceptable cache validity duration needs careful thought, based on how sensitive the protected resource is and how likely a token is to be revoked or invalidated in the meantime ⚖️. Highly sensitive environments can choose to disable caching entirely on the protected resource, which kills the risk of stale cached info completely, but again at the cost of more network traffic and server load 🚨. If the response contains the exp parameter (expiration), the response MUST NOT be cached beyond the time indicated in it ⏳.

An authorization server offering token introspection must be able to understand the token values being presented to it during this call 🧠. Exactly how it does that is an implementation detail and outside the scope of this spec. For unstructured tokens, it could be as simple as a server-side database query against a data store holding the context info for the token 🗄️. For structured tokens, the server could parse the token, validate its signature or other protection mechanisms, and return the info inside the token to the protected resource (so the protected resource doesn't need to know what's in the token, much like the client) 🧩. Note that for tokens carrying encrypted info needed during the introspection process, the authorization server must be able to decrypt and validate the token to access that info 🔑. Also note that if the authorization server stores no info about the token and has no way to get info about it by parsing the token itself, it likely can't offer an introspection service 🙃.

5. Privacy Considerations 🫶

The introspection response may contain privacy-sensitive info, like user identifiers for resource owners 👀. When that's the case, measures MUST be taken to stop this info from being disclosed to unintended parties 🚫. One method is to send user identifiers as opaque service-specific strings, potentially returning a different identifier to each protected resource 🦋.

If the protected resource sends extra info about the client's request to the authorization server (like the client's IP address) using an extension of this spec, that info could bring its own privacy considerations, which the extension should detail 🌸. The nature and implications of those extensions are outside the scope of this spec, though 💜.

Leaving privacy-sensitive info out of an introspection response is the simplest way to minimize privacy issues 🍓.

6. References 📚

6.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           DOI 10.17487/RFC5226, May 2008,
           <http://www.rfc-editor.org/info/rfc5226>.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246,
           DOI 10.17487/RFC5246, August 2008,
           <http://www.rfc-editor.org/info/rfc5246>.

[RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
           Verification of Domain-Based Application Service Identity
           within Internet Public Key Infrastructure Using X.509
           (PKIX) Certificates in the Context of Transport Layer
           Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
           2011, <http://www.rfc-editor.org/info/rfc6125>.

[RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
           RFC 6749, DOI 10.17487/RFC6749, October 2012,
           <http://www.rfc-editor.org/info/rfc6749>.

[RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
           Framework: Bearer Token Usage", RFC 6750,
           DOI 10.17487/RFC6750, October 2012,
           <http://www.rfc-editor.org/info/rfc6750>.

[RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
           2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
           August 2013, <http://www.rfc-editor.org/info/rfc7009>.

[RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
           Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
           2014, <http://www.rfc-editor.org/info/rfc7159>.

[RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
           Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
           DOI 10.17487/RFC7231, June 2014,
           <http://www.rfc-editor.org/info/rfc7231>.

[RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
           (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
           <http://www.rfc-editor.org/info/rfc7519>.

[W3C.REC-html5-20141028]
           Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
           Navara, E., 0'Connor, E., and S. Pfeiffer, "HTML5", World
           Wide Web Consortium Recommendation
           REC-html5-20141028, October 2014,
           <http://www.w3.org/TR/2014/REC-html5-20141028>.

6.2. Informative References

[BCP195]   Sheffer, Y., Holz, R., and P. Saint-Andre,
           "Recommendations for Secure Use of Transport Layer
           Security (TLS) and Datagram Transport Layer Security
           (DTLS)", BCP 195, RFC 7525, May 2015,
           <http://www.rfc-editor.org/info/bcp195>.

Appendix A. Use with Proof-of-Possession Tokens 🧿

With bearer tokens like the ones defined by OAuth 2.0 Bearer Token Usage [RFC6750], the protected resource has the entire secret portion of the token in its possession to submit to the introspection service 🔓. Proof-of-possession style tokens are different, though. There, the protected resource only has a token identifier, used during the request, along with the cryptographic signature on the request 🔏. To validate the signature on the request, the protected resource could submit the token identifier to the authorization server's introspection endpoint to get the key info it needs for that token 🗝️. The details of this usage are outside the scope of this spec, and will be defined in an extension to it, alongside the definition of proof-of-possession tokens ✨.

Acknowledgements 🫶

okay bestie, the people who made this happen deserve a shoutout 📣 Thanks to the OAuth Working Group and the User Managed Access Working Group for giving feedback and reviewing this doc 💖 Thanks also to all the implementors of both the client and server components of this spec, you're the reason it works in the real world 🔥

Special thanks from the author to Amanda Anganes, John Bradley, Thomas Broyer, Brian Campbell, George Fletcher, Paul Freemantle, Thomas Hardjono, Eve Maler, Josh Mandel, Steve Moore, Mike Schwartz, Prabath Siriwardena, Sarah Squire, and Hannes Tschofennig 👑✨ Absolute legends, every single one 😭🫶

Author's Address 📬

Justin Richer (editor) 💅

Email: ietf@justin.richer.org 🦋

📦 where this page comes from