> On May 18, 2018, at 11:55 AM, Brock Allen <brockal...@gmail.com> wrote: > > > I don’t believe code flow today with an equivalent token policy as you have > > with implicit causes any new security issues, and it does correct _some_ > > problems. The problem is that you immediately want to change token policy > > to get around hidden iframes and special parameters. > > Hidden frames and special params -- are those really the main concerns with > implicit?
They aren’t the only issues, no. The point was that you can use code flow instead of implicit, keep a 10 minute access token lifetime and no refresh token, and it doesn’t add new security concerns. The security concerns are around changing token policy once you are doing code flow, due to the execution environment of the browser. The main initial motivation around implicit was client simplicity (plus it was rather early for CORS). Once you are implementing a second iframe-based approach to discretely retrieve updated access tokens, the simplicity argument doesn’t hold. It is also an additional security consideration for the AS - ideally I want to reject my user authentication/consent content from being loaded in frames as a static policy, but now I need to allow it when prompt=none is set. This isn’t a policy recommended anyplace, just something the developers may have to argue with against the security people so that their app can have a halfway decent experience. -DW > I thought the access token being sent in the URL is a bigger concern, and > that's why code+PKCE is a better approach. > > -Brock
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
