> > the resulting consent dialog from Google is going to say "Apple is > requesting super admin privileges to your Apple account".
And that's totally fine (also assuming you meant *to your google account*. But the second provider MUST also have a prompt to the delegation of those resources. That would be a prompt specifically connecting MyCrazyLottery to Apple For example: MyCrazyLottery is requesting super admin privileges to your Apple account which will give it access to all accounts and data delegated to Apple. For instance if you have granted Apple access to your Google account, this consent will give MyCrazyLottery access to your Google account. If it isn't doing that, then this is just an incorrect or at least very lax and poorly implemented consent flow for the app. On Wed, Sep 27, 2023 at 9:37 PM David Waite <david= 40alkaline-solutions....@dmarc.ietf.org> wrote: > > > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
