Another approach to address the privacy implications of a token refresh is a client can obfuscate usage by the user by doing regular token refreshes independent of user activity.
ᐧ On Mon, Aug 31, 2020 at 10:41 AM Jeff Craig <jeffcraig= 40google....@dmarc.ietf.org> wrote: > I think that the argument is that token refreshing isn't as strong a > signal about usage patterns as introspection calls would be, which I agree > with. I also think that if a RS knows it's using an external AS, they've > generally accepted this information leakage. This is not to say it's not > worth mentioning in the document, but rather that I doubt it will > significantly move implementations one way or the other. > > Generally speaking, I don't like JWTs as Access Tokens. They're verbose, > they leak information to clients that clients don't need, and if the RS > makes a mistake in their JWT validation, they can create security > vulnerabilities. That said, I do think they are preferable to > Introspection at request time, and the RS's that I've worked with generally > don't want the overhead of Introspection on every usage of the token. I > generally argue a shared secret between the RS and the AS is a better > solution, but in my experience most cloud-hosted ASes don't offer that > option. > > For this cloud AS situation, I have been > tracking draft-ietf-oauth-token-exchange-19 as a means for RSes to setup a > Token Endpoint to convert the AS access token into a access token (w/o > Refresh) that the RS can accept, thus limiting Introspection to the Refresh > flow, but I don't currently have a RS interested in trying to try this > flow, but I think that it's a reasonable approach to limiting introspection > on every request to the RS, though it does add an additional point of > failure during the Token Refresh. This has the same leakage problem that is > under discussion here, obviously. > > On Mon, Aug 31, 2020 at 3:34 AM Neil Madden <neil.mad...@forgerock.com> > wrote: > >> But if you want to handle revocation (and you do), then the alternative >> is short-lived access tokens with frequent refreshing, which also informs >> the AS of activity. So is this any better? >> >> If an org running an RS decides to use a 3rd-party AS (eg cloud hosted) >> then there are privacy implications to that arrangement, regardless of the >> specific technology used for token validation. >> >> On 26 Aug 2020, at 22:16, Mike Jones <Michael.Jones= >> 40microsoft....@dmarc.ietf.org> wrote: >> >> >> >> I agree with Dick’s observation about the privacy implications of using >> an Introspection Endpoint. That’s why it’s preferable to not use one at >> all and instead directly have the Resource understand the Access Token. >> One way of doing this is the JWT Access Token spec. There are plenty of >> others. >> >> >> >> The downsides of using an Introspection Endpoint should be described in >> the Privacy Considerations section. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Dick Hardt >> *Sent:* Wednesday, August 26, 2020 9:52 AM >> *To:* Torsten Lodderstedt <torsten=40lodderstedt....@dmarc.ietf.org> >> *Cc:* last-c...@ietf.org; oauth <oauth@ietf.org> >> *Subject:* Re: [OAUTH-WG] Last Call: >> <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for >> OAuth Token Introspection) to Proposed Standard >> >> >> >> >> >> >> >> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <torsten= >> 40lodderstedt....@dmarc.ietf.org <40lodderstedt....@dmarc.ietf..org>> >> wrote: >> >> Hi Denis, >> >> > On 25. Aug 2020, at 16:55, Denis <denis.i...@free.fr >> <denis.i...@free..fr>> wrote: >> >> > The fact that the AS will know exactly when the introspection call has >> been made and thus be able to make sure which client >> > has attempted perform an access to that RS and at which instant of >> time. The use of this call allows an AS to track where and when >> > its clients have indeed presented an issued access token. >> >> That is a fact. I don’t think it is an issue per se. Please explain the >> privacy implications. >> >> >> >> As I see it, the privacy implication is that the AS knows * when* the >> client (and potentially the user) is accessing the RS, which is also an >> indication of *when* the user is using the client. >> >> >> >> I think including this implication would be important to have in a >> Privacy Considerations section. >> >> >> >> /Dick >> >> ᐧ >> _______________________________________________ >> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
