fix(ui_oauth): replace desktop_webview_auth with flutter_web_auth_2 by demolaf · Pull Request #693 · firebase/FirebaseUI-Flutter

demolaf · 2026-09-14T11:30:06Z

Fixes #454.

firebase_ui_oauth depended on desktop_webview_auth for desktop (macOS/Linux/Windows) OAuth sign-in. That package lives in the archived invertase/flutter_desktop_webview_auth repo and ships an iOS platform entry with no Package.swift, which breaks Swift Package Manager builds for any app that pulls in firebase_ui_auth or firebase_ui_oauth. A fix exists upstream (invertase/flutter_desktop_webview_auth#73) but can't be merged since the repo is archived.

This replaces desktop_webview_auth with flutter_web_auth_2, which is actively maintained and already ships Package.swift for both iOS and macOS. The desktop OAuth URL-building and callback-parsing logic that desktop_webview_auth previously supplied (including Twitter's OAuth 1.0a request-token signing) is vendored locally in firebase_ui_oauth, so the google/facebook/twitter provider packages needed no changes.

Preview

gemini-code-assist

Code Review

This pull request replaces the dependency on desktop_webview_auth with flutter_web_auth_2 and introduces custom OAuth implementations for Google, Facebook, and Twitter sign-in flows on desktop. The review feedback highlights several important issues: a potential CSRF vulnerability in the Facebook sign-in flow due to unvalidated state parameters, a missing 'W' in the nonce generation character set, unsafe type casting of query parameters in the Twitter sign-in flow, and incorrect configuration of FlutterWebAuth2Options for non-HTTPS redirect URIs.

Addresses gemini-code-assist findings on #693: FacebookSignInArgs generated a state nonce but never checked it against the callback, leaving the flow open to CSRF; authorizeFromCallback now rejects a mismatched or missing state before accepting the result. Also fixes the nonce character set (was missing the letter W), and stops passing FlutterWebAuth2Options.httpsHost/httpsPath for a non-https redirectUri (e.g. Twitter's custom-scheme callback), which would otherwise pass HTTPS-only options for a URL that has neither.

russellwheatley

Logic looks solid, the state validation, nonce charset, and Twitter token-secret threading all check out against your fix commits. Requesting changes mainly for the android e2e failure: flutter_web_auth_2 pulls in androidx.browser:browser:1.9.0 transitively, which needs AGP 8.9.1+, but tests/android/settings.gradle is still pinned to 8.7.3, so checkDebugAarMetadata fails on this branch. Left two inline notes too.

Addresses gemini-code-assist findings on #693: FacebookSignInArgs generated a state nonce but never checked it against the callback, leaving the flow open to CSRF; authorizeFromCallback now rejects a mismatched or missing state before accepting the result. Also fixes the nonce character set (was missing the letter W), and stops passing FlutterWebAuth2Options.httpsHost/httpsPath for a non-https redirectUri (e.g. Twitter's custom-scheme callback), which would otherwise pass HTTPS-only options for a URL that has neither.

russellwheatley · 2026-09-14T14:34:44Z

Merged #692. Following up on the AGP thread above: I'd rather not merge this with the androidx force-pin as a permanent fix. It works around twitter_login's stale AGP ceiling instead of addressing it, and we'll be back here the next time something else needs a newer AGP.

Filed CPRN-456 to replace twitter_login. Want to fold that into this PR (or land it as a prerequisite) so we bump AGP for real instead of forcing five androidx artifacts backward. Holding off on approving until we've sorted that out.

twitter_login has not published since July 2023 and ships an Android build.gradle with no namespace that pins AGP 4.1.0, which capped this repo at AGP 8.7.3 and blocked #693 from using flutter_web_auth_2. TwitterProvider now signs in through auth.signInWithProvider on Android and iOS, mirroring AppleProvider, so Firebase performs the OAuth dance and the Twitter API key and secret move out of the app binary into the Firebase console. macOS and Windows keep the vendored OAuth 1.0a flow, which is why apiKey and apiSecretKey survive as optional parameters rather than being removed. macOS stays on the desktop flow because signInWithProvider is not available to it: FLTFirebaseAuthPlugin.swift carves out Apple and Game Center, then fails every other provider under `#if os(macOS)` with unsupported-platform. Android has no equivalent restriction. - AuthAction.none throws UnsupportedError on Android and iOS, since signInWithProvider cannot return a credential without also creating a session. - Anonymous users are upgraded with linkWithProvider so the anonymous uid survives sign in. - A debug-only diagnostic warns once when apiKey or apiSecretKey are passed on a platform that now ignores them. - Restores compileSdk to flutter.compileSdkVersion and bumps AGP to 8.9.1, now that nothing pins it. BREAKING CHANGE: consumers must set the Twitter app callback URL to the Firebase auth handler, add the Encoded App ID URL scheme on iOS, and register their SHA-1 on Android. AuthAction.none now throws on Android and iOS, and the credential passed to onCredentialLinked is a plain AuthCredential rather than an OAuthCredential.

#697) * feat(ui_oauth_twitter)!: replace twitter_login with signInWithProvider twitter_login has not published since July 2023 and ships an Android build.gradle with no namespace that pins AGP 4.1.0, which capped this repo at AGP 8.7.3 and blocked #693 from using flutter_web_auth_2. TwitterProvider now signs in through auth.signInWithProvider on Android and iOS, mirroring AppleProvider, so Firebase performs the OAuth dance and the Twitter API key and secret move out of the app binary into the Firebase console. macOS and Windows keep the vendored OAuth 1.0a flow, which is why apiKey and apiSecretKey survive as optional parameters rather than being removed. macOS stays on the desktop flow because signInWithProvider is not available to it: FLTFirebaseAuthPlugin.swift carves out Apple and Game Center, then fails every other provider under `#if os(macOS)` with unsupported-platform. Android has no equivalent restriction. - AuthAction.none throws UnsupportedError on Android and iOS, since signInWithProvider cannot return a credential without also creating a session. - Anonymous users are upgraded with linkWithProvider so the anonymous uid survives sign in. - A debug-only diagnostic warns once when apiKey or apiSecretKey are passed on a platform that now ignores them. - Restores compileSdk to flutter.compileSdkVersion and bumps AGP to 8.9.1, now that nothing pins it. BREAKING CHANGE: consumers must set the Twitter app callback URL to the Firebase auth handler, add the Encoded App ID URL scheme on iOS, and register their SHA-1 on Android. AuthAction.none now throws on Android and iOS, and the credential passed to onCredentialLinked is a plain AuthCredential rather than an OAuthCredential. * fix(ui_oauth_twitter): report an error when linking without a signed in user AuthAction.link with no FirebaseAuth.currentUser null-shorted the linkWithProvider call, so the flow neither completed nor reported an error and the UI stayed in its loading state. The credential path this replaced raised through auth.currentUser!, so a null user was at least surfaced. Reports a FirebaseAuthException instead, which reaches AuthFailed rather than escaping as an unhandled Error the way a StateError would. * ci(e2e): correct stale version comment on the setup-gradle pin The pin comment claimed v6 while the pinned SHA is v6.2.0, and upstream has since moved the v6 tag to v6.3.0. zizmor flagged the mismatch as a medium severity finding, which blocks the workflow check. Corrects the comment rather than moving the pin, so the action version CI runs is unchanged. * docs(ui_oauth_twitter): document the signInWithProvider setup Rewrites the Twitter section around the flow Firebase now performs on Android and iOS: enable the provider in the console, point the X app callback URL at the Firebase auth handler, then add the encoded app ID URL scheme on iOS and the SHA-1 on Android. The twitter_login install step is gone, and the API key and secret move into their own macOS and Windows section, since those are the only platforms that still need them. Adds the encoded app ID scheme to the firebase_ui_auth example and drops the ffire:// redirect it passed for twitter_login, which no longer takes part in either flow. * fix(tests): bump the Gradle wrapper to 8.11.1 for AGP 8.9.1 AGP 8.9.1 requires Gradle 8.11.1 or later, and the tests app wrapper was on 8.10, so assembleDebug failed with a version-check error as soon as the AGP pin moved. Only the tests app is affected. The example apps keep their own lower AGP versions and wrappers. * chore(ui_oauth): format the twitter example button call * fix(ui_oauth_twitter): report auth failures instead of throwing Errors Independent review found that three of the new failure paths raised Error subtypes into the auth listener. defaultOnAuthError rethrows anything that is not a FirebaseAuthException, and both AuthFlow.onError and the button's handler catch only Exception, so those Errors escaped and left the flow in its loading state permanently. - AuthAction.none now reports a FirebaseAuthException rather than throwing UnsupportedError out of the tap handler. - Missing OAuth 1.0a credentials are checked in desktopSignIn, before the base flow reads desktopSignInArgs synchronously, so the ArgumentError is no longer reachable from the UI. - Empty strings count as missing credentials, since String.fromEnvironment yields an empty string and that is the documented way to supply them. The debug diagnostic no longer fires on them either. - User cancellation is mapped back to a flow reset. The native SDKs report dismissal as a FirebaseAuthException, which was being rendered as a sign in failure where the previous flow reset silently. - The linked credential is no longer force unwrapped, since it is nullable on every platform. Also makes the anonymous upgrade test pass AuthAction.signIn explicitly. The flow resolves to AuthAction.link whenever currentUser is non-null, so the test was passing without the shouldUpgradeAnonymous branch being consulted. * fix(ui_oauth_twitter): correct the diagnostic callback URL and two stale comments The debug diagnostic told developers to set their Twitter app callback URL to redirectUri when one was supplied, but the native flow on Android and iOS ignores redirectUri and always completes through the Firebase auth handler, so the advice guaranteed failure for exactly the consumers migrating from the custom scheme twitter_login needed. It now names the handler. The desktop flow still honours redirectUri, so its own use of it is unchanged. Also corrects the class doc, which listed Game Center alongside Apple as exempt from the macOS restriction. Game Center is rejected on every platform, for its own reason, so Apple is the only exception. And removes a comment in the example that lost its subject when the twitter_login dependency was deleted. * fix(ui_auth): navigate to the profile after a sign in that returns no email The example's sign in handler matched only emailVerified users and unverified users that have an email, so a user with neither matched no case and the screen stayed put after signing in successfully. Twitter only returns an email when the app asks for it, and such a user is never emailVerified, so Twitter sign in landed in that gap. The app's own initialRoute already treats those users as signed in via its catch all, so this brings the in flow navigation in line with what a relaunch does. * fix(ui_auth): stop EmailVerificationController crashing on resume when signed out reload() read auth.currentUser! and runs on every app resume, so resuming with no signed in user threw an unhandled TypeError rather than an Exception, which escapes the flow's error handling entirely. Cancelling an OAuth sign in is the easiest way to hit it: the provider takes the app to the background, cancelling brings it back, and currentUser is still null because the sign in never completed. Any app switch while signed out does the same, so this is not specific to a provider. The constructor already guards currentUser for null, so this brings reload() in line with the rest of the class rather than changing its contract. * chore(ui_oauth_twitter): wrap the diagnostic guard condition * docs(ui_oauth_twitter): expand the 2.x upgrade note with what testing found Device testing surfaced three things the original note could not have covered, because none of them is visible from the source. - Registering the Android SHA-1 is not sufficient on its own. The certificate hash is embedded in google-services.json at download time, so the file has to be re-downloaded afterwards. The note now carries the error string Firebase shows when either step is missed, since that is what consumers will actually search for. - Firebase occasionally opens the full browser rather than a Chrome Custom Tab, and abandoning the flow there leaves the operation pending until the app restarts. Recorded as a known limitation, since nothing in the Dart layer can resolve a future the SDK never completes. - Cancelling returns silently, which is worth stating because it is indistinguishable from nothing having happened. Also documents that redirectUri is ignored on Android and iOS, which was missing, and splits the section into what you must change, what behaviour changed, and the known limitation.

Addresses gemini-code-assist findings on #693: FacebookSignInArgs generated a state nonce but never checked it against the callback, leaving the flow open to CSRF; authorizeFromCallback now rejects a mismatched or missing state before accepting the result. Also fixes the nonce character set (was missing the letter W), and stops passing FlutterWebAuth2Options.httpsHost/httpsPath for a non-https redirectUri (e.g. Twitter's custom-scheme callback), which would otherwise pass HTTPS-only options for a URL that has neither.

desktop_webview_auth is unmaintained and its archived repo cannot ship a Package.swift for iOS, which breaks Swift Package Manager builds for any app depending on firebase_ui_auth or firebase_ui_oauth. Rewires the desktop OAuth sign-in flow in firebase_ui_oauth to use flutter_web_auth_2 instead, vendoring the provider URL-building and callback-parsing logic that desktop_webview_auth previously supplied so the google/facebook/twitter provider packages need no changes.

A fresh review of the flutter_web_auth_2 migration found two bugs. flutter_web_auth_2 only matches an https callback URL by host/path from macOS 14.4 onward; below that it completes on the first https navigation it sees, well before the OAuth provider's real redirect, so Facebook/Twitter desktop sign-in would silently break on older macOS. desktopSignIn now checks the OS version and fails loudly instead. The vendored Twitter OAuth1.0a access-token exchange also signed requests with an empty token secret, since the request token's secret was discarded instead of threaded through to the signing step, and a denied-consent callback crashed on an unsafe cast instead of cancelling cleanly. Both are fixed.

packages/firebase_ui_oauth/example/macos still targeted macOS 10.12, stale against the installed Flutter SDK's own CocoaPods requirements and below the minimum current Xcode toolchains support, so flutter build macos failed at pod install regardless of any other dependency. Bumped the Podfile and Xcode project deployment target to 12.0 to match.

Addresses gemini-code-assist findings on #693: FacebookSignInArgs generated a state nonce but never checked it against the callback, leaving the flow open to CSRF; authorizeFromCallback now rejects a mismatched or missing state before accepting the result. Also fixes the nonce character set (was missing the letter W), and stops passing FlutterWebAuth2Options.httpsHost/httpsPath for a non-https redirectUri (e.g. Twitter's custom-scheme callback), which would otherwise pass HTTPS-only options for a URL that has neither.

… message flutter_web_auth_2 pulls in androidx.browser:browser:1.9.0 on Android, which requires Android Gradle Plugin 8.9.1+. tests/android is intentionally pinned to AGP 8.7.3 pending a twitter_login release (see the compileSdk comment in tests/android/app/build.gradle), so bumping AGP isn't safe here. Force androidx.browser down to 1.8.0 instead, which doesn't carry that requirement. Also stops swallowing the underlying HTTP failure when Twitter's request-token exchange fails, per review feedback.

Forcing androidx.browser alone wasn't enough: flutter_web_auth_2 also directly depends on androidx.activity:activity-ktx 1.10.1, which pulls in an androidx.core version that also requires AGP 8.9.1+. Confirmed twitter_login still has no pub.dev release with the AGP-compatibility fix (namespace declaration merged upstream in 2024, never published; pub.dev still serves 4.4.2), so AGP stays at 8.7.3. Force the whole androidx.browser/activity/core set down to older, mutually-compatible versions instead.

#697 removed twitter_login and bumped tests/android to AGP 8.9.1, which is what androidx.browser/activity/core actually needed. The resolutionStrategy.force block added here to work around the old AGP 8.7.3 pin is no longer necessary now that this branch is rebased on top of that change.

Enables SPM for the tests app and the firebase_ui_auth example, and removes the CocoaPods-only FirebaseFirestore fork override from both Podfiles. The fork existed only to avoid compiling Firestore's C++ from source, which upstream firebase-ios-sdk makes unnecessary: over SPM it ships FirebaseFirestoreInternal as a precompiled binaryTarget, alongside prebuilt grpc, absl and openssl_grpc. That also removes the pin-drift class behind CPRN-450. With desktop_webview_auth and twitter_login gone in #693 and #697, every iOS plugin now supports SPM, so CocoaPods is fully deintegrated on iOS: Podfiles deleted, Pods build phases and xcconfig includes removed, and the Pods project dropped from the workspaces. macOS keeps CocoaPods, because facebook_auth_desktop (a transitive macOS-only implementation of flutter_facebook_auth) still ships no Package.swift, so that platform stays hybrid until it does. Two fixes were needed for SPM to resolve and build. firebase_database floated to 12.6.0, whose Package.swift pins firebase-ios-sdk with exact: 12.19.0 while firebase_core pins exact: 12.18.0, which SPM cannot reconcile; it is now pinned to 12.5.0. CocoaPods never hit this because the podspecs read one version from firebase_core at pod-install time. The Runner targets also carried IPHONEOS_DEPLOYMENT_TARGET 13.0, below the 15.0 the Firebase packages require, which CocoaPods masked and SPM enforces on the app target. The e2e caches now cover SPM's SourcePackages, with the macOS job still caching Pods alongside it. Their keys move off hashFiles('Podfile.lock') onto tests/pubspec.yaml, since Podfile.lock is gitignored and the old key was therefore constant, leaving restore-keys to do all the work. Package.resolved is gitignored alongside Podfile.lock to match the repo's lockfile convention, and the now-dead Firestore pin rewriter is removed from scripts/update_dependencies.dart.

@main

Xcode 26 and 27 reject anything below 12.0 outright, so the tests app and the firebase_ui_auth example could not be built for macOS at 10.15 on a current toolchain. This raises both, in the Xcode projects and the Podfiles, matching the bump #693 already applied to the firebase_ui_oauth example. The example's AppDelegate also picks up Xcode's modernisation, @NSApplicationMain to @main plus applicationSupportsSecureRestorableState. CI has not hit this yet because the macos-15 runner still ships an older Xcode, so this is pre-emptive rather than a fix for a current failure. ⚠️ Breaking change: the tests app and the firebase_ui_auth example now require macOS 12.0, up from 10.15. No published firebase_ui_* package is affected.

gemini-code-assist Bot reviewed Sep 14, 2026

View reviewed changes

demolaf force-pushed the ui_oauth/flutter-web-auth-2 branch from 6f164cc to 9cda555 Compare September 14, 2026 11:59

demolaf changed the base branch from main to fix/podfile-firestore-pin September 14, 2026 11:59

demolaf added this pull request to stack #694 September 14, 2026 12:02

russellwheatley requested changes Sep 14, 2026

View reviewed changes

Comment thread packages/firebase_ui_oauth/pubspec.yaml

Comment thread packages/firebase_ui_oauth/lib/src/oauth/twitter_sign_in_args.dart Outdated

demolaf requested a review from russellwheatley September 14, 2026 14:05

russellwheatley mentioned this pull request Sep 14, 2026

[firebase_ui_oauth_twitter] Replace unmaintained twitter_login dependency #696

Closed

russellwheatley approved these changes Sep 14, 2026

View reviewed changes

Base automatically changed from fix/podfile-firestore-pin to main September 14, 2026 14:34

russellwheatley force-pushed the ui_oauth/flutter-web-auth-2 branch from 4089232 to 698b91d Compare September 14, 2026 14:34

russellwheatley added the blocked: flutter label Sep 14, 2026

demolaf mentioned this pull request Sep 14, 2026

feat(ui_oauth_twitter)!: replace twitter_login with signInWithProvider #697

Merged

demolaf force-pushed the ui_oauth/flutter-web-auth-2 branch from 698b91d to b14bcf2 Compare September 17, 2026 11:46

demolaf added 7 commits September 17, 2026 14:01

demolaf force-pushed the ui_oauth/flutter-web-auth-2 branch from b14bcf2 to 9b83277 Compare September 17, 2026 13:01

demolaf merged commit eb0a212 into main Sep 17, 2026
25 checks passed

demolaf deleted the ui_oauth/flutter-web-auth-2 branch September 17, 2026 13:31

demolaf mentioned this pull request Sep 17, 2026

chore: migrate to Swift Package Manager and drop the Firestore fork #699

Open

Navigation Menu

fix(ui_oauth): replace desktop_webview_auth with flutter_web_auth_2 - #693

fix(ui_oauth): replace desktop_webview_auth with flutter_web_auth_2#693
demolaf merged 7 commits into
mainfrom
ui_oauth/flutter-web-auth-2

demolaf commented Sep 14, 2026 •

edited

Loading

Uh oh!

gemini-code-assist Bot left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

russellwheatley left a comment

Uh oh!

Uh oh!

Uh oh!

russellwheatley commented Sep 14, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

demolaf commented Sep 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Preview

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

russellwheatley left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

russellwheatley commented Sep 14, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

demolaf commented Sep 14, 2026 •

edited

Loading