> On Sep 27, 2023, at 1:18 PM, Atul Tulshibagwale <a...@sgnl.ai> wrote:
<snip> > Now if MyCrazyLottery's OPRM says it needs "super admin privileges to your > Apple account", the resulting consent dialog from Google is going to say > "Apple is requesting super admin privileges to your Apple account". This > looks safe enough to the user, and now MyCrazyLottery has way too much > privilege. Since the MyCrazyLottery app probably launched Safari in order to > get authorized, the user may not even realize it's something to do with the > "MyCrazyLottery" app that is open on their device. What's worse, any > onboarding time checks (e.g. AppStore policies) won't detect this abuse, > since MyCrazyLottery can change the OPRM at any time. I thought the guidance in this sort of dynamic case from the security topics BCP and OAuth 2.1 should be to sender-constrain and/or resource-constrain the access token, such that MyCrazyLottery is forced to be a protected resource - and cannot operate as a client to other protected resources. Resource constraints (such as requiring resource indicators) allow the AS to also institute their own protections, such as not allowing access tokens issued for MyCrazyLottery in the first place, or only allowing them with a subset of scopes. I would agree that dynamism without any sender/resource constraints is a bad idea. -DW _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
