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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
