App Check debug provider(s) provide a difficult developer experience

[mikehardy]

Step 0: Are you in the right place?

• For issues or feature requests related to the code in this repository
  file a Github issue.
  • If this is a feature request please use the Feature Request template.
• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general (non-iOS) Firebase discussion, use the firebase-talk
  google group.
• For backend issues, console issues, and other non-SDK help that does not fall under one
  of the above categories, reach out to
  Firebase Support.
• Once you've read this section and determined that your issue is appropriate for
  this repository, please delete this section.

[REQUIRED] Step 1: Describe your environment

• Xcode version: 12.5.1
• Firebase SDK version: 8.6.0
• Installation method: CocoaPods
• Firebase Component: App Check

[REQUIRED] Step 2: Describe the problem

Steps to reproduce:

This is perhaps more of a feature request, but it manifests in lots of bugs. I was requested by @maksymmalyhin to post a separate issue explaining the difficulties so here we are!

What happened? How can we make the problem occur?

In this comment I laid out the basic difficulties, it's important to understand them, it should be considered required reading for the issue but I don't want to duplicate it: firebase/flutterfire#6794 (comment)

It has lots of specific references to code that show the difficulty, it really is a solid read I think. Take your time :-)

Relevant Code:

Permalinks in the comment referenced above

Proposed Solution

My thoughts on a solution involve two key changes to the App Check system, that should span Web + Apple + Android:

Allow App Check activate with Provider changes after Firebase App Configure on all platforms

This is critical for an easy developer experience as interpreted language ecosystems (FlutterFire, react-native-firebase, others) cannot easily configure things at the native level (in AppDelegate.m prior to native configure) via AppDelegate (or java Application) native code.

If you can change the App Check Provider at runtime, then this is fine - an interpreted language framework that wraps App Check can simply determine (in whatever way is best for them!) that they are in debug mode or should use App Attest or similar post-FirebaseApp.configure and switch their Provider.

I think it's fine to put a constraint that the AppCheck Provider may not change after using any other services that App Check works with (similar to the useEmulator API usage constraints), although it would be best if the Provider could change any time and it simply purged existing tokens.

Alter DebugProviders APIs to allow configuration of shared secret via parameter

This is similar to the problem above but separate. Developers in interpreted language ecosystems frequently use configuration parameter injection frameworks that work at the dynamic language layer, and that's not running until well after the native layer is configured. When they determine they are running in an environment where they want to use the Debug Providers, they should be able to instantiate the DebugProvider with a shared secret from the dynamic language layer, then activate it.

The combination of these two changes across the various SDKs would make App Check adoption much easier for the huge audiences served via FlutterFire and react-native-firebase

Thanks!

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[mikehardy]

I believe Item 1 is possible already in firebase-js-sdk and firebase-android-sdk but Item 2 is a change that is at least needed in firebase-android-sdk as well, unsure on firebase-js-sdk.

Thank you

#8584 (comment)

[maksymmalyhin]

Thank you for the feedback and proposed solutions! We will consider it and alternatives internally and post updates here.

[maksymmalyhin]

Internally tracked in b/197661673.

[maksymmalyhin]

cc @Feiyang1 @rosalyntan

[mikehardy]

Thanks - and as you mention "alternatives internally" there are always lots of ways to do things, I'll be listening here and my github email is also valid in case you all come up with something totally different and want a sounding board. Cheers

[paulb777]

@mikehardy While I don't believe that this specific fr has been addressed, several App Check usability improvements have been made in the last few years. Is this still a need?

[mikehardy]

We have a reasonable stable "let's paper over it" solution over at react-native-firebase. Can't speak to FlutterFire repo

Our solution was to use the firebase-js-sdk APIs to work around the static-initialization-on-startup thinking baked in to the native App Check implementations and I was able to

Parts are:

• javascript API as basis (our foundational API, as react-native-firebase - which provides javascript bindings for the native SDKs is designed to be a drop-in replacement for firebase-js-sdk)
• App Check custom provider API as specific loophole (like a network localhost proxy...)
• ReactNative-specific custom provider type that provides ability to do a runtime configuration post-startup (so javascript runtime in react-native is available...)
• Native custom provider that does a facade over the built-in native providers here (the target of the proxy)

It's a lot of shimming and facading but...in the end it works and I moved on :-)

It would be better if the native stuff didn't make assumptions about being configured once and only once on startup though, that was the key hindrance

invertase/react-native-firebase#6847