🚀 Feature: Provide introspection endpoint #273

Closed
opened 2025-10-07 00:08:15 +03:00 by OVERLORD · 2 comments
Owner

Originally created by @aksdb on GitHub.

Feature description

In OAuth2 flows, where the server needs to verify the validity of a token provided by a client, it may be of use to offer token introspection as defined in RFC7662 and advertise it as introspection_endpoint in /.well-known/openid-configuration.

Pitch

An single-page-application could be a public OIDC app acquiring an access token. This is passed to a backend which has its own OIDC app. That backend can then make use of the introspection endpoint, to verify the validity of the token and extract information from it.

An application that uses it is for example OpenTalk.

Originally created by @aksdb on GitHub. ### Feature description In OAuth2 flows, where the server needs to verify the validity of a token provided by a client, it may be of use to offer token introspection as defined in [RFC7662](https://datatracker.ietf.org/doc/html/rfc7662) and advertise it as `introspection_endpoint` in `/.well-known/openid-configuration`. ### Pitch An single-page-application could be a public OIDC app acquiring an access token. This is passed to a backend which has its own OIDC app. That backend can then make use of the introspection endpoint, to verify the validity of the token and extract information from it. An application that uses it is for example [OpenTalk](https://opentalk.eu).
OVERLORD added the feature label 2025-10-07 00:08:15 +03:00
Author
Owner

@kmendell commented on GitHub:

I added the needs-more-upvotes label for now. I want to research this more as well.

Also @stonith404 please provide your input on this.

@kmendell commented on GitHub: I added the needs-more-upvotes label for now. I want to research this more as well. Also @stonith404 please provide your input on this.
Author
Owner

@stonith404 commented on GitHub:

Yes, this would make sense to add.

A client should be able to verify the access token by using the JWK from the .well-known/jwks.json endpoint but there are probably clients that use the introspection endpoint instead.

@stonith404 commented on GitHub: Yes, this would make sense to add. A client should be able to verify the access token by using the JWK from the `.well-known/jwks.json` endpoint but there are probably clients that use the introspection endpoint instead.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pocket-id#273