This raises an interesting question that I don’t think we’ve addressed yet: how to appropriately vary token lifetimes and access for different clients.
Previously, an AS could see that a client was using the implicit flow and decide to limit token lifetimes or scopes based on that alone. Similarly, I know of at least some AS implementations that let you limit what scopes you allow under the client credentials grant. The key issue is that if all your clients are using the auth code flow (which I agree they should), then how does an AS tell the difference in capabilities between incoming clients? Obviously it can do it on a per-client basis still, but now an AS is going to have to know a bit more about the app itself. Perhaps we finally need a few more entries in the “application_type” metadata parameter from OIDC’s extension RFC7591 beyond “native” and “web”? But we at least probably want to point out to AS implementors that this is something they want to consider tracking in their data model for clients. — Justin On Jul 25, 2019, at 4:04 AM, David Waite <da...@alkaline-solutions.com<mailto:da...@alkaline-solutions.com>> wrote: On Jul 24, 2019, at 3:03 PM, Aaron Parecki <aa...@parecki.com<mailto:aa...@parecki.com>> wrote: On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier <dba...@leastprivilege.com<mailto:dba...@leastprivilege.com>> wrote: <snip> I would rather say that ANY JS app should use CSP to lock down the browser features to a minimal attack surface. In addition, if refresh or access tokens are involved - further settings like disabling inline scripting (unsafe inline) and eval should be disabled. I'm not sure what to do with this suggestion. It feels like a blanket recommendation of enabling CSP will likely be ignored since it's too broad, and recommending disabling inline scripts is overreaching unless backed up by a specific threat it's protecting against. Did you have a particular threat in mind? I would say that browser applications should take measures to harden their applications again code injection and arbitrary code execution. Examples include eliminating inline script (and limiting embeddable objects as much as possible) via CSP, and versioning third party resources via techniques like subresource integrity. Mechanisms such as augmenting the codebase to make sure all appropriate user input, data storage, and output properly sanitize data may be used - although they may be more expensive to implement and audit. The AS should likewise take into account an application’s overall security posture when deciding appropriate policies around delegated authorization scopes and token lifetimes. Best current practices include turning the screws tightly around CSP. But it is (theoretically) possible to accomplish the same with brute-force sanitization, which has been made simpler with framework support. It is still ultimately the AS job to decide which clients have which capabilities. -DW _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
