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

[Vittorio Bertocci <[e-mail]>]

Hey Torsten/Tomek,
Can I ask a clarification on the below?
Torsten, you mentioned that an AS doesn't need to issue a RT- the browser
code can just repeat an authorization request. Did I get it right?
But in order to preserve the user experience, that cannot really happen as
a full page redirect; right? That wouldn't fly for any kind of background
update, or for retrieving new ATs for different resources based on the same
session. So would we now use a hidden frame to retrieve a code in the same
way in which we used fragments to get new ATs?
Thx
V.

On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt <[e-mail]>
wrote:

> Hi Tomek,
>
> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <[e-mail]>:
> >
> > Hi Torsten,
> >
> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt <
> [e-mail]> 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 <
> [e-mail]> wrote:
> > >
> > >
> > > Hi Tomek,
> > >
> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <tstojecki=
> [e-mail]>:
> > > >
> > > > 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 <
> [e-mail]> 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=
> [e-mail]> 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 <[e-mail]>
> 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
> > > >> [e-mail]
> > > >> https://www.ietf.org/mailman/listinfo/oauth
> > > >>
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > _______________________________________________
> > > OAuth mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/oauth
>
>