Hi Tomek, 

> Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <tstoje...@yahoo.com>:
> 
> Hi Torsten,
> 
> On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt 
> <tors...@lodderstedt.net> wrote:
> 
> 
> >> So if I am putting myself in the shoes of somebody who sets out to do that 
> >> - switch an existing SPA client (no backend)
> 
> > I would like to ask you a question: how many SPAs w/o a backend have you 
> > seen in your projects?
> 
> SPA (html+js) utilizing a 3rd party api that requires authorization?
> If you do have a backend, aren't you better of handling the token request on 
> the backend as pointed out here
> https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-browser-based-apps.md#javascript-app-with-a-backend-component

I agree. 

> My point of putting (no backend) in parenthesis was to not derail this 
> discussion and of course it had the opposite effect.
> 

You know, I you says „don’t look at the green car“ will cause everyone looking 
for it :-) It asked just out of curiosity. 

> >> Is that fair or is that too much of a shortcut? I am familiar with the 
> >> specs you've referenced and have looked at them again, but dealing with a 
> >> SPA, some of the recommendations are not feasible (can't authenticate the 
> >> client, 
> 
> > You could using dynamic registration (see other thread). The protection 
> > would only differ from refresh token rotation if you would use public key 
> > crypto for client authentication.
> 
> Good point. How well is dynamic registration supported across AS? 

I leave that to the vendors :-)

> 
> >> confidentiality in storage? - not sure how to read that in the context of 
> >> a browser)
> 
> > How do you ensure confidentiality of session cookies?
> 
> All I am trying to say is that I think context is important here. So when you 
> point out these best practices, some of them will get people confused as far 
> as what it means in the browser based app scenario.

That’s why we have the more general Security BCP and client-specific BCPs, like 
for native apps (https://tools.ietf.org/html/rfc8252) and the new BCP for SPAs 
Aaron started to work on.

> Maybe it is just me :)

thanks for raising the question! We need this kind of input to govern the 
development of our specs.

kind regards,
Torsten. 

> 
> > 
> > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt 
> > <tors...@lodderstedt.net> wrote:
> > 
> > 
> > Hi Tomek,
> > 
> > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki 
> > > <tstojecki=40yahoo....@dmarc.ietf.org>:
> > > 
> > > I agree with Vittorio, Dominick et al. 
> > > 
> > >> I disagree. 
> > > 
> > >> Existing deployments that have not mitigated against the concerns with 
> > >> implicit should be ripped up and updated.
> > > 
> > > Yes, just like future deployments that will not mitigate against the 
> > > concerns of code in the browser should be a concern.
> > 
> > I agree. That’s why I pointed point yesterday that the Security BCP also 
> > defines obligations for clients using code. 
> > 
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1
> > 
> > > 
> > > Can somebody on the other side of the argument (and I hate to make it 
> > > sound like there are two sides, because we're on the same side as far as 
> > > Implicit's AT in front-channel is a real issue) address Dominic's 
> > > comment: 
> > > 
> > >> Also - simply saying “implicit is evil - switch to code” means for most 
> > >> people also using refresh token - so we are treating access tokens in 
> > >> the URL with refresh tokens in session storage (over simplified - but 
> > >> you get the idea).
> > > 
> > > Does the group agree|disagree that a recommendation to switch to code 
> > > should be made as long as it is followed by an explanation and guidance 
> > > on what to do with RTs? The ideas that were floated around 
> > > - Token bound RTs (even though it was pointed out that token binding is 
> > > still considered an emerging standard). So should the recommendation than 
> > > say "switch to code and MUST use token bound RTs"?
> > > - Have AS not release RTs. "Switch to code and DO NOT request RTs"? Or 
> > > switch to code and configure AT to not release RTs for this type of 
> > > client (not sure what that even looks like in a form of a 3rd party 
> > > clients)?
> > > - RTs short lived and bound to a session - "Switch to code as long as AT 
> > > can bind and revoke RTs when you log out“
> > 
> > Basically, the AS does not need to issue refresh tokens. If the AS does not 
> > issue refresh tokens, the integration pattern for SPAs does not change 
> > (beside the code exchange). If the client needs a new access token, it will 
> > perform another authorization request.  
> > 
> > If it does, this adds another layer of security because it allows the 
> > client to frequently obtain new access tokens, which can be short-lived and 
> > scope restricted. 
> > 
> > The refresh tokens should be replay protected by issuing new refresh tokens 
> > with every refresh and detect replay for refresh tokens belonging to the 
> > same grant. 
> > 
> > The AS may additionally bind refresh tokens to AS sessions, but as it was 
> > pointed out by Annabelle and others, there are some implications to be 
> > understood and managed in that context.
> > 
> > You may find more text about refresh tokens in the Security BCP 
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12
> > 
> > kind regards,
> > Torsten.
> > 
> > 
> > > 
> > > Sorry if I have missed an important detail from the list above, people 
> > > who have proposed these ideas, feel free to clarify. 
> > 
> > > 
> > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt 
> > > <dick.ha...@gmail.com> wrote: 
> > > 
> > > 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 implementation. 
> > > 
> > > BCPs are rarely a response to a new threat, their are capturing Best 
> > > Current Practices so that they become widely deployed.
> > > 
> > > 
> > > 
> > > 
> > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell 
> > > <bcampbell=40pingidentity....@dmarc.ietf.org> wrote:
> > >> 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 recommend against it. 
> > >> 
> > >> I'm not exactly sure what that looks like in this document but maybe 
> > >> toning down some of the scarier language a bit, favoring SHOULDs vs. 
> > >> MUSTs, and including language that helps a reader understand the 
> > >> recommendations as being more considerations for new 
> > >> applications/deployments than as a mandate to rip up existing ones. 
> > >> 
> > >> 
> > >> 
> > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley <ve7...@ve7jtb.com> wrote:
> > >>> 
> > >>> We just need to be sensitive to the spin on this.  
> > >>> 
> > >> 
> > >> CONFIDENTIALITY NOTICE: This email may contain confidential and 
> > >> privileged material for the sole use of the intended recipient(s). Any 
> > >> review, use, distribution or disclosure by others is strictly 
> > >> prohibited...  If you have received this communication in error, please 
> > >> notify the sender immediately by e-mail and delete the message and any 
> > >> file attachments from your computer. 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
> > > 
> > > _______________________________________________
> > > 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to