Implement Native Authorization Screen Pop

[JohnGalt1717]

iOS, Android, Windows (at the least, likely MacOS too) all support (and require for publication to the store) that all web based authentication goes through their official process for doing authentication. Using url_launcher doesn't work with that flow. In the case of web, the only way to really make this work is to redirect, and then have js that handles the URL result and then goes back into the site (you can sort of do it with a popup window but not recommended). Linux is the odd man out and can use url_launcher.

Please consider adding support for launching the right way in all platforms for code flow etc. The AppAuth library for flutter does it correctly right now on iOS and Android and I have code that will work for web.

[DeD1rk]

Although it would be very nice to have the authentication process handled all in one by this package, I think it may be better to leave that out. The main functionality of this package is an authenticated http client. Integrating platform-specific authentication makes the package less modular and adds dependencies. As you said, there are already packages out there that can do the user-side process for you. I do think it would be good to refer to these packages in the docs and example. url_launcher and uni_links is typically not the only/best way to go, so it would be nice to have copy-pastable code with other methods.

I think by adding this more complete documentation, it can become easy to setup the authentication process, wothout adding any additional complexity to this package itself.

[jhancock4d]

So the issue is:

1. By not providing an all in one package for OpenID Connect, which virtually every application written with flutter will use, you're making all flutter apps less secure as a result.

2. Using UrlLauncher or WebView and/or uni_links you're creating both lots of opportunity to do it wrong, AND you're not doing it right anyhow to start. Android, iOS, macOS and Windows all have specific ways that all authentications MUST be done. As an example, Android must use custom tabs, similar with iOS and Windows has Authentication Browser APIs that must be called. If you use WebView on Android and iOS as an example you're actually in violation of store rules and can have your app rejected for this reason.

3. Putting together and maintaining all of the moving parts is HARD for OpenID connect so expecting people to main this when the vast majority of people using it don't even fully understand OpenID connect (there are very few that do full stop, let along app developers) is dangerous.

So maybe the solution is that this library stays as it is, but there should be a flutter library that consumes this library, provide by google/dart/flutter that does this automatically across all platforms supported by flutter and done by best practices that conform to each store's rules so that this high risk functionality is not left to non-experts that just want to add basic authentication functionality to their apps.

[DeD1rk]

Exactly. It would be awesome if the flutter/dart team would implement something like that, but I think that's unlikely. It should be quite simple to use package flutter_web_auth or flutter_appauth (I haven't tried appauth, but I think web_auth is compliant and it works quite easily). If thats very simple we can just add a code sample to the documentation of this package, otherwise we can publish a tiny package that handles the authentication process and returns a client.

[jhancock4d]

@DeD1rk The problem is that neither support anything other than ios and android and web and are likely to never support windows and linux. (and flutter_appauth won't support web officially either)

[DeD1rk]

Hmm yes that is quite problematic. I guess then there is a need for a more complete alternative, which is indeed quite complicated. It does seem that flutter_appauth is working on adding additional platforms (see https://github.com/MaikuB/flutter_appauth/issues/70), so for lack of an alternative I think it would be best to add examples with flutter_appauth to this package, and then wait/contribute for additional flutter_appauth platforms.

[jhancock4d]

@DeD1rk flutter_appauth has the same problems as the other one, because it still depends on app auth that has no intention of adding web, windows or linux support according to their own docs. I, in fact, wrote my own web implementation following standards and it won't be published to either of these because it doesn't use app_auth itself. (the javascript implementation of app_auth is for node.js only)

So we're back to where we started with no official, standards compliant, all platform openidconnect implementation for flutter which is going to induce bad, insecure code.

[DeD1rk]

I see, indeed then I think we should try to get the flutter team to maintain an interface for all platforms, perhaps (since this package is the dart-lang official one) indeed consuming this package. I'd think that since there is such a plethora of poorly made packages for specific use cases that the importance of a good solution is obvious, so we should probably open a well-documented issue on the the flutter repo. Interesting to see is https://github.com/flutter/flutter/issues/357, which was closed since good solutions exist for android and iOS (and are possible with some work for web). Of course since then the desktop platforms have been added, without good authentication solutions, so it would make sense to re-open that issue, or reference it in a new one since only collaborators can reopen the locked issue.

[jhancock4d]

@DeD1rk Also note that Web is significantly different than the other platforms so it causes even more headaches and if done wrong even more security issues. On web, you can only do a popup and wait for a response if the request comes from a button click. You cannot do so on a redirect and you can't use an iframe for SSO because of spoofing. As a result, any web implementation has to support both popup (from click) AND redirect loop functionality that redirects to the SSO site, and then back to the app. This isn't the case with android, ios, windows, linux, macos and thus massively complicates the issue. So those that are saying that they have a web implementation, in every case that I have found, don't actually have a full web implementation of code authorization flow.