Why would the client need to know the refresh token’s expiry? Can’t they just use the refresh token and see? Either way it’s a single round trip to the AS and the client gets the same answer with the same recovery code path.
— Justin > On Mar 4, 2020, at 2:01 PM, Bill Jung > <[email protected]> wrote: > > The question started when some RPs (client apps) asked that AS allow > introspection endpoint to RPs so that RPs can check their refresh token's > expiry. If AS allows this, which the spec is not clear about, then AS needs > to know if the request is coming from RP or RS so that AS can allow the > Access Token introspection to RS only. But then is that the right thing to do > even? > > Surely some clarification will eliminate the time spent on unnecessary > discussion among developers. > > <https://www.pingidentity..com/> <https://www.pingidentity.com/> > Bill Jung > Manager, Response Engineering > [email protected] <mailto:[email protected]> > w: +1 604.697.7037 > Connect with us: > <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> > <https://www.linkedin.com/company/21870> > <https://twitter.com/pingidentity> > <https://www.facebook.com/pingidentitypage> > <https://www.youtube.com/user/PingIdentityTV> > <https://www.pingidentity.com/en/blog.html> > <https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ> > <https://www.pingidentity.com/en/events/d/identify-2019.html> > <https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf> > > On Sun, Mar 1, 2020 at 9:33 PM David Waite > <[email protected] > <mailto:[email protected]>> wrote: > On Mar 1, 2020, at 10:11 PM, Andrii Deinega <[email protected] > <mailto:[email protected]>> wrote: > > > > 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)? > > In the external context, you have a client accessing a protected resource > with an access token. The client should treat the token as opaque, and > RFC7662 makes no allowances for that client to introspect its tokens. > > If you control both the client and protected resource, you may decide to > short-cut and have them share credentials. However, the client logic still > should never be introspecting the tokens. > > The security considerations also say that you must prove the authentication > of the protected resource, which I have interpreted to mean that access > tokens used to authorize the call to the introspection endpoint must be > issued to a confidential client - public clients cannot protect credentials > to perform an authentication. You want to limit introspection to prevent > denial of service and probing attacks, and to limit the amount of information > on viable attacks conveyed if someone steals a token. > > -DW > > > > > Regards, > > Andrii > > > > On Sun, Mar 1, 2020 at 7:38 PM David Waite <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > >>> <mailto:[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] > >>> <mailto:[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 > >>>> <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] <mailto:[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] <mailto:[email protected]> > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> <https://www.ietf.org/mailman/listinfo/oauth> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> [email protected] <mailto:[email protected]> > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> <https://www.ietf.org/mailman/listinfo/oauth> > >> > > > 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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
