How would the authorization server know who actually uses the introspection endpoint assuming that a protected resource and a client application use the same credentials (client_id and client_secret)?
Regards, Andrii On Sun, Mar 1, 2020 at 7:38 PM David Waite <da...@alkaline-solutions.com> wrote: > > I would expect the AS to invalidate the refresh token in this case, which > would not require a refresh token mode nor necessarily any signaling back to > the resource. > > -DW > > > On Mar 1, 2020, at 12:12 AM, Andrii Deinega <andrii.dein...@gmail.com> > > wrote: > > > > Hello Bill, > > > > I'm just thinking out loud about possible scenarios for a protected > > resource here... It may decide to revoke a refresh token if a client > > application tried to use it instead of an access token when the > > protected resource is paranoid about security. In order to do that an > > introspection response should include a non-standard parameter which > > indicates that the requested token is refresh_token. > > > > A user of the introspection endpoint should rely only on a value of > > the active parameter (which is a boolean indicator) of the endpoint > > response. This applies to both types of tokens. Note, the expiration > > date, as well as other parameters, are defined as optional in the > > specification. Both token types can be revoked before the expiration > > date comes even if this parameter is presented as part of the > > response. In my opinion, there are a number of reasons why this check > > (for a refresh token) can be useful on the client application side. > > > > -- > > Regards, > > Andrii > > > > > > On Fri, Feb 28, 2020 at 1:59 AM Bill Jung > > <bjung=40pingidentity....@dmarc.ietf.org> wrote: > >> > >> Hello, hopefully I am using the right email address. > >> > >> Simply put, can this spec be enhanced to clarify "Who can use the > >> introspection endpoint for a refresh token? A resource provider or a > >> client app or both?" > >> > >> RFC7662 clearly mentions that the user of introspection endpoint is a > >> 'protected resource' and that makes sense for an access token. If we allow > >> this to client apps, it'll give unnecessary token information to them. > >> However, the spec also mentions that refresh tokens can also be used > >> against the endpoint. > >> In case of refresh tokens, user of the endpoint should be a client app > >> because refresh tokens are used by clients to get another access token. > >> (Cannot imagine how/why a resource server would introspect a refresh token) > >> > >> Is it correct to assume that the endpoint should be allowed to client apps > >> if they want to examine refresh token's expiry time? Then the RFC should > >> clearly mention it. > >> > >> Thanks in advance. > >> > >> <Details from the spec> > >> In https://tools.ietf.org/html/rfc7662 > >> In '1. Introduction' section says, > >> "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." > >> Above makes clear that user of the endpoint is a "protected resource". > >> > >> And under 'token' in '2.1. Introspection Request' section says, > >> "For refresh tokens, > >> this is the "refresh_token" value returned from the token endpoint > >> as defined in OAuth 2.0 [RFC6749], Section 5.1." > >> So looks like a refresh token is allowed for this endpoint. > >> > >> > >> Bill Jung > >> Manager, Response Engineering > >> bj...@pingidentity.com > >> w: +1 604.697.7037 > >> Connect with us: > >> > >> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > >> material for the sole use of the intended recipient(s). Any review, use, > >> distribution or disclosure by others is strictly prohibited.. If you have > >> received this communication in error, please notify the sender immediately > >> by e-mail and delete the message and any file attachments from your > >> computer. Thank you._______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
