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

[OAUTH-WG] IETF Meetup for XYZ

Hi all, I was talking with Hannes, and we’d like to propose a dinner meetup tomorrow (Thursday) for anyone who wants to discuss XYZ in more detail while we’re here in Montreal. We’ll meet right after the ACE working group session and find a place nearby, so that some of us can get back in time

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-03.txt

Hi all, thanks for the latest round of feedback. I've incorporated these suggestions into the latest draft, -03. Here's a summary of the changes since -02: * Updated the historic note about the fragment URL clarifying that the Session History API means browsers can use the unmodified authorization

[OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 for Browser-Based Apps Authors : Aaron Parecki David Waite

Re: [OAUTH-WG] Refresh tokens

Ok thanks for the input here everyone. I'm not seeing much of a consensus, but these are all excellent points and I've collected them for discussion during the meeting on Friday. Aaron Parecki aaronparecki.com @aaronpk On Mon, Jul 22, 2019 at 8:12 AM Torsten Lo

[OAUTH-WG] OAuth 2.0 Token Exchange specification sent to the RFC Editor

I just made a blog post about the Token Exchange spec progressing to the RFC Editor queue. Congratulations all! See http://self-issued.info/?p=1992 and https://twitter.com/selfissued for the post. Cheers,

Re: [OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02

Thank you Brian for the thorough and insightful review! Comments: > On authenticated encryption. I did chat with Neil about his draft, but as you mention I didn't reference it given that it hasn't bee picked up (yet?). On referencing JWE RFC7516 and more JWA RFC7518, I am reluctant. My rationale

Re: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.

There are two primary aspects of OAuth that are undesirable in this situation: 1) Using a redirect-based OAuth flow to obtain an access token adds unnecessary attack vectors to the application (see all the redirect-based attacks in the Security BCP) 2) Storing the access token somewhere accessible

[OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley

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] New OAuth for Browser-Based Apps draft -02

*whew* this is a lot of feedback. I will try to address all of these points in this thread. On Mon, Jul 22, 2019 at 9:30 AM Torsten Lodderstedt wrote: 1) This BCP should not be limited to public clients. Your BCP itself > already describes an architecture where the OAuth client is a backend that

[OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02

2.1. Header >NOTE: there were discussions about adding a reference to >authenticated encyption methods as well, but there's no internet >draft specifying interoperable public key methods at this time > Well, Neil did write this up a while back https://tools.ietf.org/html/draft-madden-

Re: [OAUTH-WG] Language in the security BCP for cases where raw U/P is unavoidable

As the time was running out, I did not make any comment but I actually had two comments on this topic. 1) I agree with Vittorio that pushing people away from OAuth is a slippery slope. Having said that, I have no good solution either. At least, I feel that ROPC is not the right solution anyways.

[OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens Author : Vittorio Bertocci File

[OAUTH-WG] Language in the security BCP for cases where raw U/P is unavoidable

During Daniel's security BCP presentation yesterday, I commented that although I support deprecating ROPG, I also believe we should acknowledge scenarios where U/P use is unavoidable and give clear actionable guidance to developers. Daniel observed that not every scenario is prone to be addressed v

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt

Hi Petteri, thanks for your comments! Re: indicator in resource indicator One of the big goals of the profile is to promote interoperability, but ultimately the choice of what style should be used to represent ATs falls on each AS. In my experience most AS instances choose one style (opaque or JWT)

Re: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.

It would perhaps be better to phrase it as “don’t use OAuth in the JavaScript application directly” instead of “not entirely”. — Justin On Jul 23, 2019, at 12:14 AM, Leo Tohill mailto:leotoh...@gmail.com>> wrote: I didn't see the earlier discussion (do you have a date or title?) so apologies

Re: [OAUTH-WG] Transaction Authorization

I’m definitely in favor of separating the “person using the client software” from the “person making the authorization decision” and allowing them to be the same person without changing the protocol. UMA has that separation, but doesn’t handle the collapsed case very well in my opinion (in spite

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt

Hi Vittorio, Thanks for working on this. I think this will be valuable. I have a couple of comments. About relationship of this draft with token exchange, introspection and revocation: Should there be a distinct Token Type Identifier defined for JWT Access Token, to enable exchange of referen

Re: [OAUTH-WG] Transaction Authorization

I get the desire to have multiple tokens, but the real cost is the explosion in complexity for every party in the system. This is especially true if you allow the client to specify a more fine-grained and structured resource target than a scope string, but even with a scope it’s really common to

Re: [OAUTH-WG] Transaction Authorization

I agree that we need to expound on the new use cases that this approach enables, and I’ll send them out here and add them to the site as I get them written down. To your specific idea: My thinking here was that we can leverage the transaction model to make this work in a consistent fashion. Thi

[OAUTH-WG] oauth-jwsreq & parameter registration

In the WG meeting yesterday I mentioned that I thought there might have had been some action already taken with respect to "JWT Secured Authorization Request (JAR)" and the potential name conflicts between authorization parameters and JWT claims. I tracked down this ticket in the OpenID Connect WG

[OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'JWT Response for OAuth Token Introspection' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please se

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

I agree that 6.1 takes too broad of a swipe, but I'd say with same-site cookies and (sadly) without token-binding, the suggestion to use cookie based session following oauth/oidc auth is a good one and should be incorporated perhaps in 6.2? Leo sums it up well here: > We need to be clear on the