Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Neil Madden]

Good questions! Answers inline:

> On 12 Dec 2020, at 10:07, Torsten Lodderstedt  wrote:
> 
> Thanks for sharing, Neil!
> 
> I‘ve got some questions:
> Note: I assume the tokens you are referring in your article are OAuth access 
> tokens.

No, probably not. Just auth tokens more generically. 

> - carrying tokens in URLs wie considered bad practice by the Security BCP and 
> OAuth 2.1 due to leakage via referrer headers and so on. Why isn’t this an 
> issue with your approach?

This is generally safe advice, but it is often over-cautious for three reasons:

1. Referer headers (and window.referrer) apply when embedding/linking resources 
in HTML. But when we’re talking about browser-based apps (eg SPAs), that 
usually means JavaScript calling some backend API that returns JSON or some 
other data format. These data formats don’t have links or embedded resources 
(as far as the browser is concerned), so they don’t leak Referer headers in the 
same way. When the app loads a resource from a URI in a JSON response the 
Referer header will contain the URI of the app itself (most likely a generic 
HTML template page), not the capability URI from which the JSON was loaded. 
Similar arguments apply to browser history and other typical ways that URIs 
leak. 

2. You can now use the Referrer-Policy header [1] and rel=“noopener noreferrer” 
to opt out of this leakage, and browsers are moving to doing this by default 
for cross-origin requests/embeds. (This is already enabled by default in 
Safari). 

3. When you do want to use capability URIs for top-level navigation, there are 
places in the URI you can put a token that aren’t ever included in Referer 
headers or window.referrer or ever sent to the server at all - such as the 
fragment. JavaScript can then extract the token from the fragment (and then 
wipe it) and send it to the server in an Authorization header or whatever. See 
[2] for more details and alternatives. 

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
[2]: 
https://neilmadden.blog/2019/01/16/can-you-ever-safely-include-credentials-in-a-url/

> - generating (self contained) or using (handles) per URL access tokens might 
> be rather expensive. Can you sketch out how you wanna cope with that 
> challenge?

A decent HMAC implementation takes about 1-2 microseconds for typical size of 
token we’re talking about. 

> - per URL Access tokens are a very consequent Form or audience restriction. 
> How do you wanna signal the audience to the AS?

As I said, this isn’t OAuth, but for example you can already do this with the 
macaroon access tokens in ForgeRock AM 7.0 - issue a single access token and 
then make copies with specific audience restrictions added as caveats, as 
discussed in [3]. Such audience restrictions are then returned in the token 
introspection response and the RS can enforce them. 

My comment in the article about ideas for future OAuth is really just that the 
token endpoint should be able to issue multiple fine-grained access tokens in 
one go, each associated with a particular endpoint (or endpoints). You could 
either return these as separate items like:

“access_tokens”: [
{ “token”: “abc...”, 
   “aud”: “https://api.example.com/foo” },
{ “token”: “def...”,
   “aud”: “https://api.example.com/bar” }
]

Or just go ahead and combine those into capability URIs. (I think I already 
mentioned this a long time ago when GNAP was first being discussed). 

Speaking even more wishfully, what I would really love to see is a new URL 
scheme for these, something like:

  bearer://@api.example.com/foo

Which is equivalent to a HTTPS link, but the browser knows about this format 
and when clicking on/accessing such a URI it sends the token as an 
Authorization: Bearer header automatically. Ideally the browser would also not 
allow the token to be accessible from the DOM. 

Even without browser support I think such a URI scheme would be useful to allow 
GitHub and others to more easily recognise capability URIs checked into public 
git repos and perhaps provide a way to automatically revoke them 
(.well-known/token-revocation perhaps).

[3]: 
https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macaroon-access-tokens-in-am-7-0/

— Neil

> 
> best regards,
> Torsten.
> 
>> Am 12.12.2020 um 08:26 schrieb Neil Madden :
>> 
>> Not directly related to DPoP or OAuth, but I wrote some notes to help 
>> recovering XSS Nihilists: 
>> https://neilmadden.blog/2020/12/10/xss-doesnt-have-to-be-game-over/
>> 
>> — Neil
>> 
>>> On 12 Dec 2020, at 00:02, Brian Campbell 
>>>  wrote:
>>> 
>>> I think that puts Jim in the XSS Nihilism camp :) 
>>> 
>>> Implicit type flows are being deprecated/discouraged. But keeping tokens 
>>> out of browsers doesn't seem likely. There is some menton of CSP in 
>>> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07#section-9.7
>>>  
>>> 
>>> On Wed, Dec 9, 2020 at 4:10 PM Jim Manico  wrote:
 The 

Re: [OAUTH-WG] Detailed review of OAuth2.1

[Torsten Lodderstedt]

Thanks as lot Vittorio! You gave us a lot of homework but I think the draft 
will be improved a lot based on it.

Re OIDC implicit: I‘m reluctant to explicitly endorse use of OIDC implicit 
(response type „id_token“ or „code id_token“) as there are examples in the wild 
where the id_token is used as access token. Moreover, I‘m not aware of any 
systematic security threat analysis of those flows.

I‘m fine with pointing out to readers that omission of response type „token“ 
does not deprecate other extension response types.

WDYT?

> Am 09.12.2020 um 01:55 schrieb Dick Hardt :
> 
> 
> Thank you very much for your detailed feedback Vittorio!
> ᐧ
> 
>> On Tue, Dec 8, 2020 at 3:22 PM  wrote:
>> Dear authors,
>> 
>> It took ages but I finally managed to go thru a full review of the current 
>> OAuth2.1 draft. Apologies for the delay.
>> 
>> Metacomments:
>> 
>> The VAST majority of the comments are suggestions for improving clarity, 
>> mostly on historical language coming from 2.0 that I found myself having to 
>> clarify to customers and colleagues over and over thru the years. None of 
>> those are critical.
>> There are a few places where 2.1 requires a MUST I believe to be 
>> unwarranted/too restrictive. For each of those I did my best to provide 
>> context and concrete examples.
>> A sizeable category of comments and disagreements on MUST come from treating 
>> mobile and desktop apps as largely equivalent under the “native app” 
>> umbrella, despite of the vast gulf that separates the two both in terms of 
>> security posture and user experience. Again, I tried to be as matter of fact 
>> as possible in there.
>> The main reason for which I spoke up during the IETF interim on oauth2.1 was 
>> the confusion the omission f the implicit grant caused among the devs using 
>> implicit in OIDC for obtaining ID_tokens. I suggested some language to 
>> pre-empt the issue, but I expect some iteration there.
>> Thanks,
>> 
>> V
>> 
>>  
>> 
>> §1
>> 
>> I wonder whether we should take the opportunity offered by OAuth2.1 to 
>> clarify frequent points of confusion about OAuth, by explicitly calling out 
>> in the introduction what is out of scope.
>> 
>> For example: OAuth is not an identity protocol, as it doesn’t concern itself 
>> with how resource owners are authenticated; OAuth isn’t meant to address 1st 
>> party scenarios, although the reader is free to use it in that context as 
>> well; and so on.
>> 
>> I believe there is value in adding this in the introduction rather than 
>> relegating it in some later considerations section, as the people who need 
>> this information the most rarely read past this point.
>> 
>>  
>> 
>> §1.1
>> 
>> In the RS definition, wondering whether including the word “API” would help 
>> to clarify what an RS is in practice.
>> 
>>  
>> 
>> §1.2
>> 
>> I always found this part extraordinarily difficult to decipher. I get that 
>> this is the first description and doesn’t have to be exhaustive and consider 
>> all cases (eg it’s ok if step 3 claims that the client authenticates w the 
>> AS even tho that’s only for confidential clients), but I think it could be 
>> much clearer than it is today.
>> 
>> Step 1 says
>> 
>> The client requests authorization from the resource owner.  The 
>> authorization request can be made directly to the resource owner (as shown), 
>> or preferably indirectly via the authorization server as an intermediary.
>> 
>> Besides the fact that “requests authorization” is a bit vague, this step and 
>> the corresponding diagram leg does not correspond at all to what normally 
>> happens- to get a code, the client does need to hit the AS and the mention 
>> in passing in the text isn’t enough to figure that out. Also, with the 
>> omission of ROPG there really isn’t any way of asking anything to the RO 
>> directly (the client creds doesn’t involve the RO).
>> 
>> I would recommend updating that diagram to be more descriptive of the 
>> canonical scenario.
>> 
>> Step 2
>> 
>> mentions the 2 grants defined in the spec, but only one of them represents 
>> the RO’s authorization. Claiming that the client itself is the RO is a 
>> formalism that doesn’t meet the reader’s intuition at this point.
>> 
>> Step 5
>> 
>> The language here triggered multiple discussions, in particular on whether 
>> the AT can actually be used to ascertain the identity of the client – that 
>> isn’t the case for public clients, for example; besides, that’s not really 
>> the highest order bit of the AT. If it is, it seems that the spec should be 
>> more explicit about how client identification from the RS by means of an AT 
>> works. If it isn’t, perhaps we should change the language to omit 
>> authenticate.
>> 
>> The last paragraph is emblematic IMO – if the preferred method is very 
>> different from the diagram here, and if the abstraction presented here is 
>> not terribly useful (given that we no longer have multiple RO based grants, 
>> excluding the extension grants 

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Torsten Lodderstedt]

Thanks for sharing, Neil!

I‘ve got some questions:
Note: I assume the tokens you are referring in your article are OAuth access 
tokens.
- carrying tokens in URLs wie considered bad practice by the Security BCP and 
OAuth 2.1 due to leakage via referrer headers and so on. Why isn’t this an 
issue with your approach?
- generating (self contained) or using (handles) per URL access tokens might be 
rather expensive. Can you sketch out how you wanna cope with that challenge?
- per URL Access tokens are a very consequent Form or audience restriction. How 
do you wanna signal the audience to the AS?

best regards,
Torsten.

> Am 12.12.2020 um 08:26 schrieb Neil Madden :
> 
> 
> Not directly related to DPoP or OAuth, but I wrote some notes to help 
> recovering XSS Nihilists: 
> https://neilmadden.blog/2020/12/10/xss-doesnt-have-to-be-game-over/
> 
> — Neil
> 
>>> On 12 Dec 2020, at 00:02, Brian Campbell 
>>>  wrote:
>>> 
>> 
>> I think that puts Jim in the XSS Nihilism camp :) 
>> 
>> Implicit type flows are being deprecated/discouraged. But keeping tokens out 
>> of browsers doesn't seem likely. There is some menton of CSP in 
>> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07#section-9.7
>>  
>> 
>>> On Wed, Dec 9, 2020 at 4:10 PM Jim Manico  wrote:
>>> The basic theme from the web attacker community is:
>>> 
>>> 1) XSS is a game over event to web clients. XSS can steal or abuse (request 
>>> forgery) tokens, and more.
>>> 
>>> 2) Even if you prevent stolen tokens from being used outside of a web 
>>> client, XSS still allows the attacker to force a user to make any request 
>>> in a fraudulent way, abusing browser based tokens as a form of request 
>>> forgery.
>>> 
>>> 3) There are advanced measures to stop a token from being stolen from a web 
>>> client, like a HTTPonly cookies and to a lesser degree, JS Closures and 
>>> Webworkers. 
>>> 
>>> 4) However, these measures to protect cookies are mostly moot. Attackers 
>>> can just force clients to make fraudulent requests.
>>> 
>>> 5) Many recommend the BFF pattern to hide tokens on the back end, but 
>>> still, request forgery via XSS allows all kinds of abuse.
>>> 
>>> XSS is game over no matter how you slice it.
>>> 
>>> Crypto solutions do not help. Perhaps the world of OAuth can start 
>>> suggesting that web clients use CSP 3.0 in specific ways, if you still plan 
>>> to support Implicit type flows or tokens in browsers?
>>> 
>>> Respectfully,
>>> 
>>> - Jim
>>> 
>>> 
>>> 
>>> On 12/9/20 12:57 PM, Brian Campbell wrote:
 Thanks Philippe, I very much concur with your line of reasoning and the 
 important considerations. The scenario I was thinking of is: browser based 
 client where XSS is used to exfiltrate the refresh token along with 
 pre-computed proofs that would allow for the RT to be exchanged for new 
 access tokens and also pre-computed proofs that would work with those 
 access tokens for resource access. With the pre-computed proofs that would 
 allow prolonged (as long as the RT is valid) access to protected resources 
 even when the victim is offline. Is that a concrete attack scenario? I 
 mean, kind of. It's pretty convoluted/complex. And while an access token 
 hash would reign it in somewhat (ATs obtained from the stolen RT wouldn't 
 be usable) it's hard to say if the cost is worth the benefit.
 
 
 
 On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck 
  wrote:
> Yeah, browser-based apps are pure fun, aren’t they? :)
> 
> The reason I covered a couple of (pessimistic) XSS scenarios is that the 
> discussion started with an assumption that the attacker already 
> successfully exploited an XSS vulnerability. I pointed out how, at that 
> point, finetuning DPoP proof contents will have little to no effect to 
> stop an attack. I believe it is important to make this very clear, to 
> avoid people turning to DPoP as a security mechanism for browser-based 
> applications.
> 
> 
> Specifically to your question on including the hash in the proof, I think 
> these considerations are important:
> 
> 1. Does the inclusion of the AT hash stop a concrete attack scenario?
> 2. Is the “cost” (implementation, getting it right, …) worth the benefits?
> 
> 
> Here’s my view on these considerations (specifically for browser-based 
> apps, not for other types of applications):
> 
> 1. The proof precomputation attack is already quite complex, and short 
> access token lifetimes already reduce the window of attack. If the 
> attacker can steal a future AT, they could also precompute new proofs 
> then. 
> 2. For browser-based apps, it seems that doing this complicates the 
> implementation, without adding much benefit. Of course, libraries could 
> handle this, which significantly reduces the cost. 
> 
> 
> Note that these comments are specifically to 

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Vladimir Dzhuvinov]

If the current DPoP has code complexity "X", the relative additional
complexity to include access token hashes doesn't seem like very much.
An app choosing DPoP means accepting the code complexity that comes with
dealing with keys, composing the signing inputs for the proofs, signing,
the necessary changes to the token and RS requests. On the other hand,
for some people that additional access token hash may become the straw
that breaks the camel's back, causing them to quit their jobs developing
web apps and never look back :)

Have you thought about letting deployments decide about the access token
hash? To say look, there is also the option to bind an access token to
the DPoP proof, the security benefits can be such an such, and this is
how it can be done.

What I don't like about that proposal:

  * It will complicate the spec

  * The current spec doesn't require implementers / deployments to make
any decisions, apart from adopt / not DPoP (okay, also choose a JWS
alg) - which is actually a great feature to have


Vladimir


On 12/12/2020 01:58, Brian Campbell wrote:
> Any type of client could use DPoP and (presumably) benefit from
> sender-constrained access tokens. So yeah, adding complexity
> specifically for browser-based applications (that only mitigates one
> variation of the attacks possible with XSS anyway)  has 'cost' impact
> to those clients as well. And should be considered in the
> cost/benefit. Including the AT hash isn't terribly complicated but
> it's not trivial either. I'm honestly still unsure but am leaning
> towards it not being worth adding.
>
> On Fri, Dec 11, 2020 at 2:14 AM Philippe De Ryck
>  > wrote:
>
> The scenario you describe here is realistic in browser-based apps
> with XSS vulnerabilities, but it is pretty complex. Since there
> are worse problems when XSS happens, it’s hard to say whether DPoP
> should mitigate this. 
>
> I’m wondering what other types of clients would benefit from using
> DPoP for access tokens? Mobile apps? Clients using a Client
> Credentials grant?
>
> How are they impacted by any change made specifically for
> browser-based applications?
>
> Philippe
>
>
>> On 9 Dec 2020, at 23:57, Brian Campbell
>> mailto:bcampb...@pingidentity.com>>
>> wrote:
>>
>> Thanks Philippe, I very much concur with your line of reasoning
>> and the important considerations. The scenario I was thinking of
>> is: browser based client where XSS is used to exfiltrate the
>> refresh token along with pre-computed proofs that would allow for
>> the RT to be exchanged for new access tokens and also
>> pre-computed proofs that would work with those access tokens for
>> resource access. With the pre-computed proofs that would allow
>> prolonged (as long as the RT is valid) access to protected
>> resources even when the victim is offline. Is that a concrete
>> attack scenario? I mean, kind of. It's pretty convoluted/complex.
>> And while an access token hash would reign it in somewhat (ATs
>> obtained from the stolen RT wouldn't be usable) it's hard to say
>> if the cost is worth the benefit.
>>
>>
>>
>> On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck
>> > > wrote:
>>
>> Yeah, browser-based apps are pure fun, aren’t they? :)
>>
>> The reason I covered a couple of (pessimistic) XSS scenarios
>> is that the discussion started with an assumption that the
>> attacker already successfully exploited an XSS vulnerability.
>> I pointed out how, at that point, finetuning DPoP proof
>> contents will have little to no effect to stop an attack. I
>> believe it is important to make this very clear, to avoid
>> people turning to DPoP as a security mechanism for
>> browser-based applications.
>>
>>
>> Specifically to your question on including the hash in the
>> proof, I think these considerations are important:
>>
>> 1. Does the inclusion of the AT hash stop a concrete attack
>> scenario?
>> 2. Is the “cost” (implementation, getting it right, …) worth
>> the benefits?
>>
>>
>> Here’s my view on these considerations (*/specifically for
>> browser-based apps, not for other types of applications/*):
>>
>> 1. The proof precomputation attack is already quite complex,
>> and short access token lifetimes already reduce the window of
>> attack. If the attacker can steal a future AT, they could
>> also precompute new proofs then. 
>> 2. For browser-based apps, it seems that doing this
>> complicates the implementation, without adding much benefit.
>> Of course, libraries could handle this, which significantly
>> reduces the cost. 
>>
>>
>> Note that these comments are specifically to