> > 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. >
I would very much like to see that. native/web possibly in combination with token_endpoint_auth_method and the client being DCR or "static" is far from being enough to make a policy decision. S pozdravem, *Filip Skokan* On Thu, 25 Jul 2019 at 13:45, Justin Richer <[email protected]> wrote: > 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 <[email protected]> > wrote: > > > > > On Jul 24, 2019, at 3:03 PM, Aaron Parecki <[email protected]> wrote: > > On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier > <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
