+1 Phil
> On Dec 18, 2018, at 10:14 AM, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > > Hi Hannes, > > while I think the current text needs some substantial work, I support the > adoption of this draft as a working group document. I also think we need to > carefully define the boundaries between the Security BCP and the SPA BCP in > order to prevent unnecessary duplications and inconsistencies. > > Here are my review comments: > > "OAuth 2.0 authorization requests from apps running entirely in a > browser are unable to use a Client Secret during the process, since > they have no way to keep a secret confidential.“ > > Although I think that’s an important aspect I’m wondering why the draft > starts with it? I don’t think this is the most important message. If the > intend is to align with https://tools.ietf.org/html/rfc8252, I would propose > something like > > „OAuth 2.0 authorization requests from browser based apps should only be made > using the code flow. …" > > Section 3 > > "Browser-based application": An application that runs entirely in a > web browser, usually written in JavaScript, where the source code > is downloaded from a domain prior to execution. Also sometimes > referred to as a "single-page application", or "SPA“. > > I think this definition is too narrow, which also limits applicability of > this draft. I would argue a browser based application runs portions of its > logic in the browser but not necessarily the entire app. Most browser based > apps have a backend in the same way as mobile apps have a backend. I think > for the purpose of this draft the fact that the UI is controlled from within > the browser, uses browser APIs and underlies browser security mechanisms & > restrictions is much more important. Moreover, the source code not even needs > to be downloaded for every execution due to browser caching. > > My proposal: > > "Browser-based application": An application that is dynamically > downloaded and executed in a web browser, usually written in > JavaScript. Also sometimes referred to as a "single-page application", or > "SPA“. > > Section 4 > > "Require the OAuth 2.0 state parameter" -> "Use the the state parameter to > carry one-time use CSRF tokens" > > "...require the > hostname of the redirect URI match the hostname of the URL the app > was served from“ > > Are we sure there are no legit reasons to receive the redirect at another > host? Is the AS supposed to determine the app's origin from the referrer > header? > > "Previously it was recommended that browser-based applications use the > OAuth 2.0 Implicit flow. …“ > > I suggest to mention broad adoption of CORS after publication of RFC 6749 as > reason why the shift towards code is possible now. > > Section 5 > > „To conform to this best practice, first-party applications using > OAuth or OpenID Connect MUST use an OAuth Authorization Code flow as > described later in this document or use the OAuth Password grant." > > It does not feel well for me to read „MUST" and "Password grant“ in the same > sentence. I'm in favor to just recommend 1st party apps to use code for > reasons x, y, z and not mention password. > > I also think the arguments are more dominante when formatted as bullet list. > > Section 6 > > "In some cases, it may make sense to avoid the use of a strictly > browser-based OAuth application entirely, instead using an > architecture that can provide better security.“ > > Reads like OAuth implies degraded app security? > > 6.1. > > „For simple system architectures, such as when the JavaScript > application is served from the same domain as the API (resource > server) being accessed, it is likely a better decision to avoid using > OAuth entirely, and just use session authentication to communicate > with the API.“ > > What do you mean by same domain? same second level domain? same host? I'm not > sure what this text want to convey. > > Section 6.2. > > 2nd paragraph „….The backend component essentially becomes a new > authorization server“ > > I get the message, but the term "authorization server" misled me when I read > the text for the first time. I was under the impression, your are proposing > OAuth as communication protocol between an app's front and backend. This is > possible but just one option. I suggest to remove the term. It does not > really help. > > 3rd paragraph „In this scenario, the backend component may be a confidential > client > which is issued its own client secret. „ > > Confidential clients can use various authentication methods, „secret" > misleads reader towards traditional client secrets. private_key_jwt and mTLS > are possible (and better options). > > „Despite this, there are still > some ways in which this application is effectively a public client, > as the end result is the application's code is still running in the > browser and visible to the user.“ > > Why does this make the SPA a public client? I see the risk of a browser based > app (and every kind of attacker) to access protected APIs through the > backend. That's the reason why I think the backend should never directly > expose (== just proxy) the underlying RS APIs. The interface between front > and backend must be narrowed down to the specific use case AND the current > state of the app. For example, if the app is in "check out" state it makes > sense to initiate a payment but in no other state. > > General remark: I would suggest to restructure section 6 to describe the > potential architectures this BCP has in mind. From my perspective these are: > - "pure" SPA > - SPA w/ backend > - SPA w/o OAuth (as fallback) > > Section 7.1 > > „Public browser-based apps MUST implement the Proof Key for Code extension to > OAuth, and authorization > servers MUST support PKCE for such clients." > > Any client MUST use PKCE (see Security BCP) - PKCE is used beyond > interception prevention to detect injection. Please refer to section 2.1 of > the security BCP it has all the details. > > Section 7.2 > > „Authorization servers SHOULD require an exact match of a registered > redirect URI." > > Please make it a MUST as stated in the Security BCP, Section 2.1 > > „ If an authorization server wishes to provide some flexibility in > redirect URI usage to clients, it MAY require that only the hostname > component of the redirect URI match the hostname of the URL the > application is served from.“ > > Why do you soften the Security BCP requirements? That's the road to open > redirection! > > Section 8 > > This section lacks a motivation for RT usage. In my opinion, there are two > reasons: > (1) use RTs instead of refresh via authorization code flow (to cope with > ITP2). > (2) be able to issue short lived and privilege restricted access tokens in > order to limit the impact of access token leakage at resource servers. > > Both are good reasons that deserve dedicated discussions. I therefore suggest > to split & change Section 8 into two sections, „Access Token Refresh" and > „Access Token Replay Mitigation". > > The section on access token mitigation should discuss potential options, > including > - Token Binding > - mTLS > - RT rotation > … > > Section 9.1 > > This BCP describes different SPA design where such apps can be either public > or confidential. So I would not preclude confidential clients. > > Section 9.4 > > You might want to refer to the Security BCP as it has more details on this > topic. > > I would also suggest to add use of CORS for CSRF protection in the browser > (see https://www.ietf.org/mail-archive/web/oauth/current/msg18591.html) since > it is SPA specific. > > Section 9.6. > > I would argue enabling CORS is not a security consideration but a functional > requirement towards the AS. > > 2nd paragraph > > CORS and authorization of GET&POST requests plays a vital role in CSRF > prevention if the access tokens are conveyed in a cookie as well as for any > automatic way to add authorization headers to outbound requests (see above). > So I think it must be managed properly. > > Section 9.7 > > Why do you bind CSP to RTs or long living access tokens. Isn’t this anyway a > good idea to prevent XSS? > > Section 9.8.6 > > injection is neglected - I think you could just refer to the Security BCP for > the discussion of the risks associated with implicit. If any threat is > missing there, we can add it there. > > „In OpenID Connect, …“ > > Not clear to me what this text shall convey. Is it a statement in favor of > issuing id tokens in the back channel in OIDC? > > Section 9.8.7 > > I would put this text in a motivation section along with the explanation why > CORS adoption allows code adoption for SPAs in the introduction of the BCP. > > kind regards, > Torsten. > > >> Am 17.12.2018 um 22:01 schrieb Hannes Tschofenig <hannes.tschofe...@arm.com>: >> >> Hi all, >> >> We would like to get a confirmation on the mailing list for the adoption of >> https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02 as a >> starting point for a BCP document about *OAuth 2.0 for Browser-Based Apps*. >> >> Please, let us know if you support or object to the adoption of this >> document by Jan. 7th 2019. >> >> Ciao >> Hannes & Rifaat >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> >> _______________________________________________ >> 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
