OAuth 2.0 Token Introspection
RFC 7662

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09
• 10
• 11

Internet Engineering Task Force (IETF)                    J. Richer, Ed.
Request for Comments: 7662                                  October 2015
Category: Standards Track
ISSN: 2070-1721

                     OAuth 2.0 Token Introspection

Abstract

   This specification defines a method for a protected resource to query
   an OAuth 2.0 authorization server to determine the active state of an
   OAuth 2.0 token and to determine meta-information about this token.
   OAuth 2.0 deployments can use this method to convey information about
   the authorization context of the token from the authorization server
   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 Notice

   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.

Richer                       Standards Track                    [Page 1]
RFC 7662                   OAuth Introspection              October 2015

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

   In OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients.
   This means that the client does not need to know anything about the
   content or structure of the token itself, if there is any.  However,
   there is still a large amount of metadata that may be attached to a
   token, such as its current validity, approved scopes, and information
   about the context in which the token was issued.  These pieces of
   information are often vital to protected resources making
   authorization decisions based on the tokens being presented.  Since
   OAuth 2.0 does not define a protocol for the resource server to learn
   meta-information about a token that it has received from an
   authorization server, several different approaches have been
   developed to bridge this gap.  These include using structured token
   formats such as JWT [RFC7519] or proprietary inter-service
   communication mechanisms (such as shared databases and protected
   enterprise service buses) that convey token information.

   This specification defines a protocol that allows authorized
   protected resources to query the authorization server to determine
   the set of metadata for a given token that was presented to them by
   an OAuth 2.0 client.  This metadata includes whether or not the token
   is currently active (or if it has expired or otherwise been revoked),
   what rights of access the token carries (usually conveyed through
   OAuth 2.0 scopes), and the authorization context in which the token