Originally posted by **danj3** July 30, 2024
There's a line in oidcc_token_introspection.erl:extract_response:
```
IntrospectionClientId == ClientId; IntrospectionClientId == undefined
```
Which seems to mean that the function will only introspect a token that was issued by the client of the caller (i.e. one's own token) or a token issued elsewhere but only to a client_id of the same name.
Somehow this seems incorrect and not very useful, but maybe I misunderstand the intent of these words (from https://datatracker.ietf.org/doc/html/rfc7662):
```
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
was granted (including who authorized the token and which client it
was issued to). Token introspection allows a protected resource to
query this information regardless of whether or not it is carried in
the token itself, allowing this method to be used along with or
independently of structured token values. Additionally, a protected
resource can use the mechanism described in this specification to
introspect the token in a particular authorization decision context
and ascertain the relevant metadata about the token to make this
authorization decision appropriately.
```
It would seem that this constraint would just need to be removed to fix the problem. Unless there is another mechanism for validating a token through the AS?
Discussed in https://github.com/erlef/oidcc/discussions/362