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

[Tomek Stojecki <[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.

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"

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