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
