[Planning] Major package refactor

[ahmednfwela]

The package currently needs a major refactor in the following areas:

1. launching a url and getting a response
   • this is currently inconsistent between web and io
   • I suggest adding 4 extra federated packages openidconnect_android, openidconnect_ios, openidconnect_macos, openidconnect_linux
   • each package might not necessarily need platform-dependent code, and some of them can use existing packages (e.g. url_launcher, flutter_appauth, etc...)
2. OIDC discovery
   • while the package conforms to the spec for the most part, it needs extra unit tests
3. Token persistence
   • The package is tightly coupled with flutter_secure_storage which isn't fully supported on web, so we need to decouple it and let each platform decide
4. OpenIdIdentity
   • should be transformed to a plain object, and move persistence logic elsewhere
5. Reorganizing the package to use exports instead of part/part of
   • see https://dart.dev/guides/libraries/create-library-packages#organizing-a-library-package
6. CI/CD on the github repo to automate package publishing
   • see https://dart.dev/tools/pub/automated-publishing
7. Support Multi-tenancy

[jhancock4d]

1. There is a package for windows but it was removed because it just uses device code as does macos and linux right now which works basically the same to how they'd work anyhow. The reason I added a windows one was speculative because WinRT (WinUI now) has full captured browser window functionality for going to an IdP. My intent was to wait for FFI and then implement it in dart as I have in the past on Xamarin.

Not sure there is much of a win ever for linux and not just using device_code for linux. MacOS may have similar to iOS, I don't know. In that case it might be interesting to have device specific federation for it like windows.

Android and iOS were kept in the main package because there were pretty major issues with splitting them out when I wrote this. They could be split out now, though not sure if it really matters.

3. flutter_secure_storage has as close to web support as any library (I wrote the functionality for flutter_secure_storage and contributed it specifically to make it work with this project because there was no secure storage for web anywhere else at the time. To keep as much code shared I'd strongly suggest that it stays there and any issues with the web integration in flutter_secure_storage be fixed (if possible... web doesn't do encrypted secured storage well at all)

4. See above. The intent is to share all of that instead of having to maintain it separately. Don't reinvent the wheel if you don't need to. (and web crypto especially for this is really hard so we shouldn't be trying to maintain it in this library anyhow)

5. Not sure what this buys anything. As soon as you use exports you're exposing stuff that should never be imported.

6. 👍

[ahmednfwela]

@jhancock4d also since the package doesn't have a verified publisher on pub.dev

should we create a new domain for it? or just transform it to our publisher https://pub.dev/publishers/bdaya-dev.com/packages ?

[jhancock4d]

Google disconnected the publisher on name change for some reason. It has been fixed.