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