We're basically on the same page, I think. I Was just coming from the perspective that once you've solved the iframe problem (say via a library), then it's six and one, or half a dozen and another, so to speak. Of course if the spec were redone today, it would look different and able to take into consideration what we have available today.
But you mention a 10-minute only access token. Without a refresh token, then you do have to resort back to the iframe, and then we're back at square one. But again, I'm still agreeing with you :) As for prompt=none and the OP/AS wanting to set static policy to prevent iframes (presumably you mean with XFO/CSP), I don't see that as a problem. In my experience, those response headers don't apply when the response is just a 302 back to the redirect uri. They only are take effect when the response is rendering HTML. So you can set those globally in your OP/AS and it can still handle prompt=none properly. Unless I'm misunderstanding your last point. -Brock On 5/18/2018 2:21:06 PM, David Waite <da...@alkaline-solutions.com> wrote: On May 18, 2018, at 11:55 AM, Brock Allen <brockal...@gmail.com [mailto: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
