Thanks Torsten!So if I am putting myself in the shoes of somebody who sets out
to do that - switch an existing SPA client (no backend) from Implicit to Code,
the options to think through can be summed up more or less as following:
1. Do not use RTs2. If you're using RTs, rotate on every refresh AND implement
RT token binding (is that stable enough?). Also consider binding RT to AS
session.
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,
confidentiality in storage? - not sure how to read that in the context of a
browser)
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
