Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Belated +1 to this. "sender or key constrained" is good. Also, the new definition of "sender constrained" per Torsten states "knowledge of" but that is only applicable to "key constrained" variant I guess, besides "knowledge" is a bit "fluffy". I feel that just saying as suggested by Brian

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hannes, As long as the client is a server-based application, MTLS works fine, and my use-case is exactly that. On the side note: perhaps we may want to take the remaining portion of JPOP up in the near future, as its usefulness is there as Tony pointed out at the time we ported the certs based

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I disagree. Existing deployments that have not mitigated against the concerns with implicit should be ripped up and updated. For example, at one time, I think it was Instagram that had deployed implicit because it was easier to do. Once the understood the security implications, they changed the

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are saying here. And that was kind of behind the comment I made, or tired to make, about this in Bangkok, which was (more or less) that I don't think the WG should be killing implicit outright but rather that it should begin to

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

On Sat, Dec 1, 2018 at 5:01 AM Torsten Lodderstedt wrote: > > my proposal is to add the following definition (based on 3.8.1.2) to a new > „Terminology" section or to section 2.1.2: > > A sender constrained access token scopes the applicability of an access > token to a certain sender. This

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

I would also like to see something to that effect. I feel that sometimes because SPAs use APIs, there's an unchallenged assumption that OAuth also has to be used with the in-browser code accessing those APIs. Even if the details are out of scope for this document, some text like the below at least

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Not everyone loves OAuth. Sometimes our discussions on how to make it more secure can be taken out of context and used as reasons to move back to proprietary solutions. We just need to be sensitive to the spin on this. John B. On Mon, Dec 3, 2018, 3:43 PM Torsten Lodderstedt > > > Am

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

I support adding something to that effect, but would like to make it clear that this removes the app from being covered under this BCP. How about: --- Implementations MAY consider moving the authorization code exchange and handling of access and refresh tokens to a backend component in order to

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> Am 03.12.2018 um 12:59 schrieb John Bradley : > > I agree that the hair on fire messaging is over stated. > > This is still a document in development and not yet a BCP. No new vunerable > have been found, but attackers are evolving. You are right. Basically, RFC 6749’s security

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I agree that the hair on fire messaging is over stated. This is still a document in development and not yet a BCP. No new vunerable have been found, but attackers are evolving. These are security best practices for new implimentations. Not a recommendation to rip things out.As

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I agree with Vittorio - While we all agree that implicit is outdated and we can do better (and it is indeed good that this discussion has finally started for real) - the communication around the (preliminary) results of the BCP was unfortunate and not very responsible - quoting: “Simply put, the

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

Interesting. Even on this list people felt to see that moving some logic to a backend could solve some of the problems raised. What I want to convey is: the solution to a problem in the OAuth space does not necessarily need to be found on the OAuth protocol level. That’s a best practice in the

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi all, Sorry for stepping a bit back from the level of detail the discussion already reached. I do have some specific comments on the document, but before bringing those up I wanted to raise a general problem I am experiencing with this initiative. I have a number of customers that are reacting

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

This is my point. >From a security perspective we have a server based confidential client. The fact that it has a angular or other JS UI protected by a cookie seems to not be especially relucent to OAuth. Perhaps from the developer point of view they have a JS SPA and the only difference to

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

(chair hat off) Hi Nat, Section 3.8.1.2 of draft-ietf-oauth-security-topics-10 lists the following options for implementing sender constraint tokens: * Token Binding * MTLS * Signed HTTP Requests

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

We also are talking about a stronger attacker model than what was assumed before, and there are good reasons for that:   * We see more dynamic setups now which enable new kinds of attacks. With the AS Mix-Up attack, for example, we have seen that tokens and codes can leak in unexpected ways. PKCE

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

> On Dec 3, 2018, at 1:25 AM, Torsten Lodderstedt > wrote: > > I think the BCP needs to point out there are solutions beyond an app directly > interacting with AS and RSs from the browser. Otherwise people get the wrong > impression this is the only way to go. To the contrary and as I

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

(chair hat off) I believe many in this group had concerns with the implicit grant already for a long time but thought it was necessary for use with JavaScript-based apps in the browser. Two things have happened in the meanwhile * Attempts to secure the implicit grant, for example with

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

I think the BCP needs to point out there are solutions beyond an app directly interacting with AS and RSs from the browser. Otherwise people get the wrong impression this is the only way to go. To the contrary and as I pointed out, there are a lot of SPAs working as UI of a larger application.