Torsten, Great document!
Some minor nits and comments: Abstract - double period after first sentence. > It updates and extends the OAuth 2.0 Security Threat Model to > incorporate practical experiences gathered since OAuth 2.0 was > published and cover new threats relevant due to the broader > application of OAuth 2.0. When I first read, it sounds like this is a replacement for the threat model or at least could be read that way. I think you mean readers still need to read 6819. How about... "This specification uses the OAuth 2.0 Security Threat Model and supplements it to incorporate practical experiences gathered"... Section 1. The paragraph starting “OAuth initially assumed a static…” appears to continue the previous bullet point. Should the paragraph be indented? Last paragraph 3.1.1 > This kind of injections is covered in > Section Code Injection. Should this say Section 3.5? Section 3.1.5 This paragraph seems unfinished... > > Question: Does redirect uri validation solve any problem for > native apps? Effective against impersonation when used in > conjunction with claimed HTTPS redirect URIs only. > For Windows token broker exact redirect URI matching is important > as the redirect URI encodes the app identity. For custom scheme > redirects there is a question however it is probably a useful part > of defense in depth. Section 3.4 > AS returns client_id and its iss in the response. Client compares > this data to AS it believed it sent the user agent to. “client_id” and “iss” attributes do not appear to have any marking (<spanx style=“verb”>) in multiple locations in the document. Section 3.5 > How does an attack look like? How about: "An attack looks like:” Writing style of the following comment seems like an editors note rather than a comment for the reader. Rephrase? > But this approach conflicts with the idea to enforce exact redirect > URI matching at the authorization endpoint. Moreover, it has been > observed that providers very often ignore the redirect_uri check > requirement at this stage, maybe, because it doesn't seem to be > security-critical from reading the spec. Is this appropriate for a BCP (seems like a WG discussion item)? > The authors therefore propose to the working group to drop this > feature in favor of more effective and (hopefully) simpler approaches > to code injection prevention as described in the following section. Section 3.5.1 This seems a bit tentatively worded… > PKCE seem to be the most obvious solution for OAuth clients as it > available and effectively used today for similar purposes for OAuth > native apps whereas "nonce" is appropriate for OpenId Connect > clients. Formatting problem (missing line between paragraphs)? > Note on pre-warmed secrets: An attacker can circumvent the > countermeasures described above if he is able to create or capture > the respective secret or code_challenge on a device under his > control, which is then used in the victim's authorization request. > Exact redirect URI matching of authorization requests can prevent the > attacker from using the pre-warmed secret in the faked authorization > transaction on the victim's device. > Unfortunately it does not work for all kinds of OAuth clients. It is > effective for web and JS apps and for native apps with claimed URLs. > Attacks on native apps using custom schemes or redirect URIs on > localhost cannot be prevented this way, except if the AS enforces > one-time use for PKCE verifier or Nonce values. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com <mailto:phil.h...@oracle.com>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
