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.scurte...@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.masak...@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 >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
