Okay,
Marius, Filip and Nat, thank you for your answers. :)

On Wed, Sep 11, 2019 at 3:51 AM Nat Sakimura <[email protected]> wrote:

> As Filip mentioned, I feel that claimed HTTPS URI would help. Further, if
> that is used within the dynamic client registration, it could be more
> secure.
>
> The security assumptions are
>
> 1. Phone is not rooted;
> 2. App Store's vetting of claimed URI is not compromised; etc.
>
> Nat Sakimura
> Chairman, OpenID Foundation
> https://nat.sakimura.org
> 2019年9月11日 4:27 +0900、Masakazu OHTSUKA <[email protected]>のメール:
>
> I see.
>
> Then is this understandable to think from the Authorization Server's point
> of view ...
>
> If phone being compromised is a threat that the Client cares,
> AS might be interested in NOT supporting public Clients,
> and forcing the Client to have a server side, do client authentication,
> and have some way to hold a session between the native app and it's server
> side.
>
> Because if phone is compromised, when AS supports public Clients and
> access_token leaks, it's kind of AS's fault (well depending on the
> terms...),
> but if whatever the means that the phone app and it's server side keeps a
> session leaks, it's NOT the AS's fault.
>
>
> On Tue, Sep 10, 2019 at 8:23 PM Marius Scurtescu <
> [email protected]> wrote:
>
>> If the phone is compromised, original app replaced by malicious app, then
>> RFC8252 will not help. The assumption is that the phone is not compromised.
>>
>> On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA <[email protected]
>> <[email protected]>> wrote:
>>
>>> Hi,
>>>
>>> I've read rfc8252 and have questions about native apps, that I couldn't
>>> find answers on Internet.
>>>
>>> Imagine an attacker doing:
>>> 1. original app and authorization server conforms to rfc8252 4.1.
>>> Authorization Flow for Native Apps Using the Browser
>>> 2. clone the original app, name it malicious app and install on the
>>> target phone
>>> 3. remove the original app from the target phone
>>> 4. use the malicious app and authorize, OS will invoke malicious app
>>> using custom URL scheme
>>> 5. now malicious app has access to the access token
>>>
>>> How should we think about this?
>>> What am I missing?
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to