How can IndieAuth protect users against fake clients with webviews?

[saschanaz]

For example, WebAuthenticationBroker.authenticateAsync() on Microsoft Windows captures the redirection and get the queries from the URL, without having to own the domain of the redirection URL at all. In that case, how can a user know the client in their hand is not fake and actually linked to the client_id URL?

[saschanaz]

Perhaps the authorization servers need to block webviews, as Google and Dropbox do since 2016?

• https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

In the coming months, we will no longer allow OAuth requests to Google in embedded browsers known as “web-views”, such as the WebView UI element on Android and UIWebView/WKWebView on iOS, and equivalents on Windows and OS X.

The device browser also provides improved security as apps are able to inspect and modify content in a web-view

• https://www.dropbox.com/developers/documentation/http/documentation#oauth2-authorize

Your app should send the user to this app authorization page in their system browser, which will display the permissions being granted. If the user isn't already signed in to the Dropbox website, they will be prompted to do so on this web page. This web page should not be displayed in a web-view. This is in order to maintain compatibility with the website and to comply with Google's policy against processing their OAuth flow inside a web-view, to support users who sign in to Dropbox using their Google accounts.

[JBYoshi]

How would a "fake client" be defined? There's a really large gray area here. For example, quite a few legitimate browsers are simply wrappers around a system-provided web view (off the top of my head, this includes most browsers on iOS due to Apple restrictions, as well as DuckDuckGo for Mac). Similarly, someone could insert a full copy of an open-source browser engine into their app and apply whatever changes they want; at what point does it stop being a legitimate browser and become a fake client?

Standard OAuth 2.0 already has no protections against malicious applications (as noted in the Best Current Practices document, section 4.1.4), so I don't think IndieAuth can do much better.

In addition, end users could be educated about phishing attacks and best practices, such as only accessing trusted clients, as OAuth does not provide any protection against malicious applications and the end user is solely responsible for the trustworthiness of any native application installed.

[saschanaz]

Thanks, that helps!