Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard
Hi all, On Mon, Aug 31, 2020 at 09:58:11AM +0200, Denis wrote: > The last text that has been proposed on the list about this thread is > the following: > > Implementers should be aware that a token introspection request lets the > AS know when the client is accessing the RS, > which can also indicate when the user is using the client. If > this implication is not acceptable, implementers can use other means > to carry access token data, e.g. directly transferring the data > needed by the RS within the access token. > > The concerns of the implementers have nothing to do with the concerns of > the Users. Such a text proposal has nothing to do with a "User consent". > > *Towards an RFC Errata to RFC 7662* > > Mike Jones 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. > > I fully agree. > > RFC 7662 should have incorporated a more detailed content such as: > > In OAuth 2.0 [RFC6749], the contents of tokens are opaque to > clients. However, the contents of tokens is not intended to be opaque to > RSs. > Token introspection is an OPTIONAL feature of an AS described in > OAuth Introspection [RFC 7662] intended for clients that are unable > to support structured access tokens including their validation. > The use of this call allows an AS to track where and when its clients > have indeed > presented an issued access token. As soon as the RS knows the > format of the access token, e.g. using structured token formats such as > JWT [RFC7519], and is able to validate its security features, the > call described in OAuth Introspection [RFC 7662] should be avoided, > otherwise > 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. As soon as this call is > supported by an AS, the client or the user have no way to prevent the RS > to use it. > > It might be useful to add it, e.g. using an RFC Errata. I do not believe this would be an appropriate usage of an Errata Report -- it changes the meaning of the RFC away from what the WG intended at the time of publication. Use of tokens that are just opaque DB handles (along with some form of introspection) is desirable when a prominent threat is leakage of token contents from the browser. We have had numerous discussions over the years of various ways in which information can leak from the browser, including history APIs, malicious javascript, and more. While these threats are not always applicable in all deployment models, they are still present, just as the threats that you propose we defend against are not always of concern in all deployment models. AFAICT, given the technologies currently available, there is not one universal solution that will address all concerns, and deployments will have to make a trade-off. I think we need to acknowledge that there are different deployment models and that (for example) giving the user visibility into the token contents is not always desired, given the other risks that the current mechanisms for providing that visibility open up. -Ben P.S. your usage of the phrase "the User and his client" (below) suggests that you are still picturing the client as being local to the user, as is the case for, e.g., a TLS client or an IMAP client. This is not the original model for an OAuth, where the client can just as well be a headless server in a cloud somewhere. > *Differences with RFC 7662* > > RFC 7662 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. > > At a first glance, draft-ietf-oauth-jwt-introspection-response-09 seems > to be simply a JWT Response for OAuth Token Introspection > instead of a JSON document representing the meta information surrounding > the token. > > However, this is not the case since major differences can be identified. > > RFC 7662 describes an OPTIONAL call able to return a JSON object with > the following top-level members: active (REQUIRED), scope (OPTIONAL), > client_id (OPTIONAL), username (OPTIONAL), token_type (OPTIONAL), exp > (OPTIONAL), iat (OPTIONAL), nbf (OPTIONAL), sub (OPTIONAL), > aud (OPTIONAL), iss (OPTIONAL), jti (OPTIONAL) and claims from the "JSON > Web Token Claims" registry (OPTIONAL). > > draft-ietf-oauth-jwt-introspection-response-09 is able to return a JWT > as the introspection response. However, the request and the returned > information > are not the same. > > Section 4 (Requesting a JWT Response) only provides an example and does
Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard
> On 31 Aug 2020, at 18:41, Jeff Craig 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. It’s usually pretty similar in my experience (see below). > 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. Right. > > 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. Generally you’d cache the result of the introspection call to mitigate this overhead. (Eg some reverse proxies or API gateways can do this). The two approaches are pretty similar: either you have 10 second access tokens and refresh, or you introspect and cache the response for 10 seconds. I much prefer introspection because there are far fewer ways to mess it up, but the JWT approach can be useful if you have clients accessing a lot of different RSes. > 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 >> 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 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 On Behalf Of Dick Hardt >>> Sent: Wednesday, August 26, 2020 9:52 AM >>> To: Torsten Lodderstedt >>> Cc: last-c...@ietf.org; oauth >>> Subject: Re: [OAUTH-WG] Last Call: >>> (JWT Response for >>> OAuth Token Introspection) to Proposed Standard >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt >>> wrote: >>> >>> Hi Denis, >>> >>> > On 25. Aug 2020, at 16:55, Denis 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
Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard
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 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 > 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 > 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 *On Behalf Of * Dick Hardt >> *Sent:* Wednesday, August 26, 2020 9:52 AM >> *To:* Torsten Lodderstedt >> *Cc:* last-c...@ietf.org; oauth >> *Subject:* Re: [OAUTH-WG] Last Call: >> (JWT Response for >> OAuth Token Introspection) to Proposed Standard >> >> >> >> >> >> >> >> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt > 40lodderstedt@dmarc.ietf.org <40lodderstedt@dmarc.ietf..org>> >> wrote: >> >> Hi Denis, >> >> > On 25. Aug 2020, at 16:55, Denis > > 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
Re: [OAUTH-WG] WGLC Review of PAR
I'm not sure how to word it exactly but I think Dick has landed on what we ultimately want this to say. Basically that the "request_uri" is intended to be used only once, the client MUST not use it more than once, and that the AS should also treat it as one-time use but may make reasonable accommodations to more gracefully handle redundant authorization requests due to browser reload or similar. On Sun, Aug 30, 2020 at 4:48 PM Dick Hardt wrote: > I don't have the context of the text to respond to the exact wording, but > I think we can state that the client MUST use the "request_uri" only once, > and then explain that the AS may receive duplicate requests if the browser > is reloaded. > > > On Sat, Aug 29, 2020 at 4:24 AM Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> You are making a good point here. The reason we added the one time use >> constraint was the fact the client will include parameters supposed to be >> used only once, e.g. the PKCE code_challenge. For a traditional >> authorisation request, we would recommend the client to use a per >> transaction (== one time use) code_challenge, but PKCE does not require the >> AS to enforce it. Mapping this to PAR means, we SHOULD recommend the client >> to use the request_uri only once but not require the AS to enforce it. >> >> Would the following text work for you? >> >> Since parts of the request content, e.g. the "code_challenge" >>parameter value, is unique to a certain authorization request, >> the client SHOULD use the "request_uri" only once. >> >> I also would move this text to section 4. >> >> > On 27. Aug 2020, at 18:11, Dick Hardt wrote: >> > >> > That is not correct. >> > >> > The authorization code one-time-use is directly between the client and >> the AS. The client has a number of mechanisms to ensure it only presents >> the authorization code to the AS once, such as a session that was set when >> the user started at the client. >> > >> > In contrast, in a redirect from the client to the AS, the client loses >> control on how many times the user-agent loads the URL at the AS. >> Additionally, there is unlikely to be an active browser session at the AS, >> so the AS can not easily differentiate between a URL load from the same >> user, or different users. If one-time-use, one of them MUST fail. If the >> two requests happen to be from the same user (because of a reload, which >> the user did because the AS was slow to respond), there is no way for the >> AS to know which of the requests is the one that is current in front of the >> user. While the AS can internally ensure processing of the request once, >> one-time-use would dictate that it provides a failure message to one of the >> requests. >> > >> > /Dick >> > >> > >> > ᐧ >> > >> > On Thu, Aug 27, 2020 at 7:17 AM Justin Richer wrote: >> > We already have this same property with authorization codes, and it’s >> managed today reasonably well (in my opinion). If you submit the same >> request URI twice in the same browser (the refresh you’re talking about), >> it shouldn’t start two separate authorization requests, but it would be >> reasonable to detect that the same session attached to the same request URI >> value showed up twice and continue the session as appropriate. >> > >> > None of this is in conflict with “one time use”, in my view, since >> you’re actively detecting the session and source of the value. >> > >> > — Justin >> > >> >> On Aug 26, 2020, at 6:16 PM, Dick Hardt wrote: >> >> >> >> I think one-time use may be overly restrictive, and I don't think it >> is the property that we actually want. >> >> >> >> Give the request URI is in a redirect from the browser, there is a >> good chance of a race condition where the same browser request is made more >> than once, for example, while the browser is loading the authorization URL >> at the AS, the user could refresh the page causing the authorization URL to >> be reloaded. Would the reload count as a second use? One could argue it >> either way. >> >> >> >> What I think we want from what I understand, is the request URI MUST >> be unique so that there is no confusion on which request is being >> referenced. >> >> >> >> I did not see anything about the expiry time of the request URI (but I >> did not look super hard). If that is not there, then I think the request >> URI MUST expire in a "short" period of time. >> >> >> >> >> >> >> >> ᐧ >> >> >> >> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote: >> >> Thanks Justin. Just a couple more responses to responses inline below >> (but with lots of content that needs no further discussion removed). >> >> >> >> A TL;DR for the WG is that I'd like to get some wider feedback on the >> question of changing the one-time-use condition on the request_uri from a >> SHOULD to a MUST. >> >> >> >> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer wrote: >> >> Hi Brian, just a couple responses inline where it seemed fitting. >> Thanks
Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard
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 > 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 On Behalf Of Dick Hardt > Sent: Wednesday, August 26, 2020 9:52 AM > To: Torsten Lodderstedt > Cc: last-c...@ietf.org; oauth > Subject: Re: [OAUTH-WG] Last Call: > (JWT Response for OAuth > Token Introspection) to Proposed Standard > > > > On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt > wrote: > Hi Denis, > > > On 25. Aug 2020, at 16:55, Denis 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
Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard
The last text that has been proposed on the list about this thread is the following: Implementers should be aware that a token introspection request lets the AS know when the client is accessing the RS, which can also indicate when the user is using the client. If this implication is not acceptable, implementers can use other means to carry access token data, e.g. directly transferring the data needed by the RS within the access token. The concerns of the implementers have nothing to do with the concerns of the Users. Such a text proposal has nothing to do with a "User consent". *Towards an RFC Errata to RFC 7662* Mike Jones 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. I fully agree. RFC 7662 should have incorporated a more detailed content such as: In OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients. However, the contents of tokens is not intended to be opaque to RSs. Token introspection is an OPTIONAL feature of an AS described in OAuth Introspection [RFC 7662] intended for clients that are unable to support structured access tokens including their validation. The use of this call allows an AS to track where and when its clients have indeed presented an issued access token. As soon as the RS knows the format of the access token, e.g. using structured token formats such as JWT [RFC7519], and is able to validate its security features, the call described in OAuth Introspection [RFC 7662] should be avoided, otherwise 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. As soon as this call is supported by an AS, the client or the user have no way to prevent the RS to use it. It might be useful to add it, e.g. using an RFC Errata. *Differences with RFC 7662* RFC 7662 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. At a first glance, draft-ietf-oauth-jwt-introspection-response-09 seems to be simply a JWT Response for OAuth Token Introspection instead of a JSON document representing the meta information surrounding the token. However, this is not the case since major differences can be identified. RFC 7662 describes an OPTIONAL call able to return a JSON object with the following top-level members: active (REQUIRED), scope (OPTIONAL), client_id (OPTIONAL), username (OPTIONAL), token_type (OPTIONAL), exp (OPTIONAL), iat (OPTIONAL), nbf (OPTIONAL), sub (OPTIONAL), aud (OPTIONAL), iss (OPTIONAL), jti (OPTIONAL) and claims from the "JSON Web Token Claims" registry (OPTIONAL). draft-ietf-oauth-jwt-introspection-response-09 is able to return a JWT as the introspection response. However, the request and the returned information are not the same. Section 4 (Requesting a JWT Response) only provides an example and does not describe the mandatory and optional parameters from the request. Are they identical to those described in RFC 7662 ? No one is able to say. draft-ietf-oauth-jwt-introspection-response-09 describes a response structure which is different from RFC 7662 where a single top-level member is required, i.e. active. The text from draft-ietf-oauth-jwt-introspection-response-09 requires three (in fact four) top-level members. The text states: The JWT MUST include the following top-level claims: * issMUST be set to the issuer URL of the authorization server. * audMUST identify the resource server receiving the token introspection response. * iatMUST be set to the time when the introspection response was created by the authorization server. Note that the text about "active" (i.e. the fourth top-level member) is misplaced in the middle of the token_introspection claim and does not allow to easily understand that the top-level claim "active" MUST be set to either true or false. The text states: The AS determines based on its RS-specific policy what claims about the resource owner to return in the token introspection response. Such a sentence (which does not exist in RFC 7662) is a door wide-opened to return claims that are NOT included into the access token. This protocol should NOT be a protocol that allows authorized RSs to query the AS to obtain metadata that was NOT included into an access token that was presented to them. Torsten wrote: Token introspection has several advantages over structured access tokens, also when it comes to privacy. If one uses a structured access token in conjunction with different *services*, then
