Re: [OAUTH-WG] Public client cloning

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 <
marius.scurtescu@coinbase.com> 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 <o.masakazu@gmail.com>
> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>