The scenario I am concerned about is: Say a user is using a trusted client (e.g. my Apple Mac <substitute any mega corp that you consider trustworth>) and has a trusted authorization server (e.g. Google <substitute...>). But a relatively untrusted app (e.g. MyCrazyLottery) on the device the user is accessing a resource (e.g. MyCrazyLottery). 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.
On Tue, Sep 26, 2023 at 8:51 AM Tom Jones <thomasclinganjo...@gmail.com> wrote: > Kind of interesting to consider this to be a security consideration. It > depends on whose security is being considered. I have always thought that > the only way for the subject to approach a request for data is as a privacy > threat. The attacker is the "client" every time. Sometimes it is something > attacking the client, but the client is the data fiduciary. > > The actual threat to the client is running a foul of the GDPR. The > penalties can be pretty high. Maybe this should be called privacy or > conduct risk. In any case there needs to be corporate policy imposed on the > developers. > > thx ..Tom (mobile) > > On Tue, Sep 26, 2023, 8:31 AM George Fletcher <george.fletcher= > 40capitalone....@dmarc.ietf.org> wrote: > >> Hi Justin, >> >> Whether the scopes are known or unknown to the developer, I don't think >> it changes the "attack vector" which is to get the client to request more >> privilege than it should in a given circumstance. Maybe the attacker has a >> way to capture the token once it issues (this of course can be mitigated by >> using sender constrained tokens but how many are deploying that solution >> internally?). >> >> I think a security consideration makes sense given the client is likely >> just going to use whatever is provided in the meta-data. Either the AS >> needs a way to ensure clients only request the authorization needed for the >> current task, or clients need a way to filter the scopes specified. The >> latter is more likely but we don't have a good way to convey the intent of >> the access token outside of the Resource Indicators specification (which >> again I'm not sure is widely implemented). >> >> Thanks, >> George >> >> On Tue, Sep 26, 2023 at 10:54 AM Justin Richer <jric...@mit.edu> wrote: >> >>> I think we’re used to thinking of scopes in terms of things that a >>> developer can read and understand, but that’s not always going to be true. >>> For automated systems like this, the developer isn’t always expected to >>> understand the scope — they probably don’t even see it in many cases. The >>> client software knows the API, but at the OAuth layer, the client just >>> needs to know what values to put into the OAuth flow to be able to call the >>> RS and have it work. That value could very well be an opaque string, which >>> is supported by the 6750 response header already as well. >>> >>> — Justin >>> >>> On Sep 22, 2023, at 1:58 PM, Atul Tulshibagwale <a...@sgnl.ai> wrote: >>> >>> Hi, >>> >>> #1 is clear now. Thanks Warren >>> On #2, thanks Neil and Warren for your clarifications. Does it make >>> sense to include language that warns against requesting unknown scopes in >>> the OPRM draft? >>> >>> Atul >>> >>> On Thu, Sep 21, 2023 at 11:17 AM Neil Madden <neil.e.mad...@gmail.com> >>> wrote: >>> >>>> On 21 Sep 2023, at 17:19, Atul Tulshibagwale <a...@sgnl.ai> wrote: >>>> >>>> >>>> Hi all, >>>> I'm still looking for answers to these two questions >>>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/NLj-xnAZ4BtFs9z62OzCro4xxoc/__;!!FrPt2g6CO4Wadw!MEkYNnqe_LL_FW1ouclB0RBHsbCXu5Sr6qR4EVjLtaJjO3I0Zs2HnTOPGRxPOFdyzUU0SgtBOKJmDjfgrfRk05Eh$> >>>> regarding the OPRM draft that was recently adopted by the WG: >>>> >>>> 1. If I have a resource server that has multiple endpoints, each of >>>> which require different scopes, how should those be handled? For >>>> example, >>>> in the SSF spec, the SSF Transmitter has a Create Stream endpoint and a >>>> Polling endpoint. The scopes required for these are different. How would >>>> the client know which scope is to be used with which endpoint? >>>> 2. Does the spec encourage insecure behavior in the caller by >>>> requesting tokens with scopes that they do not understand? I.e. If an >>>> authorization server is known to provide valuable tokens with certain >>>> scopes, can a malicious resource server trick the client into >>>> requesting a >>>> more powerful token, which it then uses to access some other service? >>>> Since >>>> the consent dialog is likely to show two trusted names (i.e. the >>>> requesting >>>> client and the authorization server), the user would be prone to >>>> providing >>>> consent, even if the scope looks unnecessarily permissive. >>>> >>>> Regarding point 2, if this is a threat then it's already enabled by RFC >>>> 6750, which defines the `WWW-Authenticate: Bearer scope="..."` challenge >>>> header that can be used to indicate which scopes a client needs to access a >>>> resource. Even just misleading documentation for how to access the RS could >>>> enable this threat. That's not to say that this isn't worth considering (it >>>> is), but I don't think this draft makes the situation worse than now. >>>> >>>> -- Neil >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!MEkYNnqe_LL_FW1ouclB0RBHsbCXu5Sr6qR4EVjLtaJjO3I0Zs2HnTOPGRxPOFdyzUU0SgtBOKJmDjfgrbbg2Cqq$> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!MEkYNnqe_LL_FW1ouclB0RBHsbCXu5Sr6qR4EVjLtaJjO3I0Zs2HnTOPGRxPOFdyzUU0SgtBOKJmDjfgrbbg2Cqq$ >>> >> ------------------------------ >> >> The information contained in this e-mail is confidential and/or >> proprietary to Capital One and/or its affiliates and may only be used >> solely in performance of work or services for Capital One. The information >> transmitted herewith is intended only for use by the individual or entity >> to which it is addressed. If the reader of this message is not the intended >> recipient, you are hereby notified that any review, retransmission, >> dissemination, distribution, copying or other use of, or taking of any >> action in reliance upon this information is strictly prohibited. If you >> have received this communication in error, please contact the sender and >> delete the material from your computer. >> >> >> >> >> _______________________________________________ >> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
