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://mailarchive.ietf.org/arch/msg/oauth/NLj-xnAZ4BtFs9z62OzCro4xxoc/>
> regarding the OPRM draft that was recently adopted by the WG:
> 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?
> 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
