Konubinix' opinionated web of thoughts

OAuth 2.0 Token Introspection

fleeting

OAuth 2.0 token Introspection

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

https://datatracker.ietf.org/doc/html/rfc7662

contents of tokens are opaque to clients

https://datatracker.ietf.org/doc/html/rfc7662

client does not need to know anything about the content or structure of the token itself, if there is any

https://datatracker.ietf.org/doc/html/rfc7662

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

https://datatracker.ietf.org/doc/html/rfc7662

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

https://datatracker.ietf.org/doc/html/rfc7662

different approaches […] include using structured token formats such as JWT [RFC7519]

https://datatracker.ietf.org/doc/html/rfc7662

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

https://datatracker.ietf.org/doc/html/rfc7662

Actually, the format of the introspected claims is almost the same as the one defined in JWT.

server responds with a JSON object [RFC7159] in “application/ json” format with the following top-level members.

active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The specifics of a token’s “active” state will vary depending on the implementation of the authorization server and the information it keeps about its tokens, but a “true” value return for the “active” property will generally indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity (e.g., after its issuance time and before its expiration time). See Section 4 for information on implementation of such checks.

scope OPTIONAL. A JSON string containing a space-separated list of scopes associated with this token, in the format described in Section 3.3 of OAuth 2.0 [RFC6749].

client_id OPTIONAL. Client identifier for the OAuth 2.0 client that requested this token.

username OPTIONAL. Human-readable identifier for the resource owner who authorized this token.

token_type OPTIONAL. Type of the token as defined in Section 5.1 of OAuth 2.0 [RFC6749].

exp OPTIONAL. Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token will expire, as defined in JWT [RFC7519].

iat OPTIONAL. Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token was originally issued, as defined in JWT [RFC7519].

nbf OPTIONAL. Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token is not to be used before, as defined in JWT [RFC7519].

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

aud OPTIONAL. Service-specific string identifier or list of string identifiers representing the intended audience for this token, as defined in JWT [RFC7519].

iss OPTIONAL. String representing the issuer of this token, as defined in JWT [RFC7519].

jti OPTIONAL. String identifier for the token, as defined in JWT [RFC7519].

https://datatracker.ietf.org/doc/html/rfc7662

Notes linking here