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 <[email protected]> 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 > <[email protected]> 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 >> [email protected] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
