Re: [OAUTH-WG] [External Sender] Re: Questions on OAuth Protected Resource Metadata

[Warren Parad]

>
> 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  wrote:

>
>
> > On Sep 27, 2023, at 1:18 PM, Atul Tulshibagwale  wrote:
>
> 
>
> > 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

Re: [OAUTH-WG] [External Sender] Re: Questions on OAuth Protected Resource Metadata

[David Waite]

> On Sep 27, 2023, at 1:18 PM, Atul Tulshibagwale  wrote:



> 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

Re: [OAUTH-WG] [External Sender] Re: Questions on OAuth Protected Resource Metadata

[Atul Tulshibagwale]

BTW I'm trying to conjure a scenario where there is a system level request
from the app that results in the consent being asked by Apple, and not
directly by the app acting as an OAuth client.

On Wed, Sep 27, 2023 at 12:18 PM Atul Tulshibagwale  wrote:

> The scenario I am concerned about is: Say a user is using a trusted client
> (e.g. my Apple Mac )
> and has a trusted authorization server (e.g. Google ). 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 
> 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 > 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  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  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 
 wrote:

> On 21 Sep 2023, at 17:19, Atul Tulshibagwale  wrote:
>
>
> Hi all,
> I'm still looking for answers to these two questions
> 
> 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 

Re: [OAUTH-WG] [External Sender] Re: Questions on OAuth Protected Resource Metadata

[Atul Tulshibagwale]

The scenario I am concerned about is: Say a user is using a trusted client
(e.g. my Apple Mac )
and has a trusted authorization server (e.g. Google ). 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 
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  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  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  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 
>>> wrote:
>>>
 On 21 Sep 2023, at 17:19, Atul Tulshibagwale  wrote:


 Hi all,
 I'm still looking for answers to these two questions
 
 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 
 

Re: [OAUTH-WG] [External Sender] Re: Questions on OAuth Protected Resource Metadata

[Tom Jones]

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  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  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  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 
>> wrote:
>>
>>> On 21 Sep 2023, at 17:19, Atul Tulshibagwale  wrote:
>>>
>>>
>>> Hi all,
>>> I'm still looking for answers to these two questions
>>> 
>>> 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
>> 
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>>
>> 

Re: [OAUTH-WG] [External Sender] Re: Questions on OAuth Protected Resource Metadata

[George Fletcher]

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  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  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 
> wrote:
>
>> On 21 Sep 2023, at 17:19, Atul Tulshibagwale  wrote:
>>
>>
>> Hi all,
>> I'm still looking for answers to these two questions
>> 
>> 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
> 
>
>
> ___
> 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