Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

, is it not acting as a public client without a client secret? Nat From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Thursday, July 25, 2019 8:45 PM To: David Waite Cc: OAuth WG Subject: Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps This raises an

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

> I agree, I removed the mention of OIDC. If that means you'd leave the OAuth prohibition, it's still misleading or confusing. OIDC is of course an extension of or layer over OAuth. If you prohibit OAuth, you prohibit OIDC. You don't mean it that way, but that's the way it reads. On Thu, Jul

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

I also think it would be useful, but a problem is that things like “application type” are usually a stand in for a whole bunch of different attributes that we actually care about. That’s what happened with web/native and why, to my knowledge, nobody really uses those in lieu of things like publi

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

> > Obviously it can do it on a per-client basis still, but now an AS is going > to have to know a bit more about the app itself. Perhaps we finally need a > few more entries in the “application_type” metadata parameter from OIDC’s > extension RFC7591 beyond “native” and “web”? But we at least prob

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

This raises an interesting question that I don’t think we’ve addressed yet: how to appropriately vary token lifetimes and access for different clients. Previously, an AS could see that a client was using the implicit flow and decide to limit token lifetimes or scopes based on that alone. Similar

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

> On Jul 24, 2019, at 3:03 PM, Aaron Parecki wrote: > > On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier > wrote: > >> I would rather say that ANY JS app should use CSP to lock down the browser >> features to a minimal attack surface. In addition, if refresh or access >> tokens are involve

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

To clarify. Using CSP is a general best practice for every JS app. Once tokens are stored in the browser you want to specifically focus on injection attacks (XSS) - disabling inline scripting is key to that. ——— Dominick On 24. July 2019 at 23:04:20, Aaron Parecki (aa...@parecki.com) wrote: On

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier wrote: > I think you are mixing authentication and API access here. Depending on > application scenario it makes a lot of sense to use OIDC - but rely on the > resulting session to control API access. > Unless you want to dive into the details here

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

Not sure I follow - the current OAuth security topics BCP allows for using either state or PKCE for detecting CSRF (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4..7.1 ), with some caveats

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

Yes it would. ——— Dominick On 23. July 2019 at 10:08:43, Filip Skokan (panva...@gmail.com) wrote: Wouldn’t that contradict the security topics BCP? Odesláno z iPhonu 23. 7. 2019 v 9:44, Neil Madden : Technically it could be optional, but it means that a CSRF attempt will only be detected by t

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

Wouldn’t that contradict the security topics BCP? Odesláno z iPhonu 23. 7. 2019 v 9:44, Neil Madden : > Technically it could be optional, but it means that a CSRF attempt will only > be detected by the AS not by the client. If we consider the possibility of a > malicious AS, then this could al

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

Technically it could be optional, but it means that a CSRF attempt will only be detected by the AS not by the client. If we consider the possibility of a malicious AS, then this could allow Login CSRF attacks against the client. The client would also have to be sure that the AS actually implemen

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

Forgot one more thing In 7.1 Browser-based apps MUST use the OAuth 2.0 "state" parameter to protect themselves against Cross-Site Request Forgery and authorization code swap attacks and MUST use a unique value for each authorization request, and MUST verify the returned state in the a

[OAUTH-WG] Feedback on OAuth for browser-based Apps

Hey, Just read the spec - good to see the progress. Some feedback: I am yet undecided if I like the categorisation of the “Application Architecture Patterns”. I definitely want to distinguish between applications only accessing same-site back-end services and “others”. Not sure if “dynamic applic