[OIDAuthorizationSession resumeExternalUserAgentFlowWithURL:] crash
Describe the bug An OAuth redirect was sent to a OIDExternalUserAgentSession after it already completed. - An OAuth redirect was sent to a OIDExternalUserAgentSession after it already completed.
To Reproduce
Fatal Exception: An OAuth redirect was sent to a OIDExternalUserAgentSession after it already completed.
0 CoreFoundation 0x11a21c __exceptionPreprocess
1 libobjc.A.dylib 0x31abc objc_exception_throw
2 CoreFoundation 0x178ea0 -[NSException initWithCoder:]
3 Blueground 0x37ef5c -[OIDAuthorizationSession resumeExternalUserAgentFlowWithURL:] + 137 (OIDAuthorizationService.m:137)
4 Blueground 0x372eb0 -[GIDSignIn handleURL:] + 200 (GIDSignIn.m:200)
5 Blueground 0x366ca8 protocol witness for GoogleSignInProvider.handle(:) in conformance GIDSignIn (
Expected behavior Not to crash.
Environment
- Device: Iphone
- OS: iOS 18.x
- Google Sign-in SDK: v 9.0
We are getting the same crash after migrating from 6.2.4 to 9.0.0.
we met the same issue after migrating from 6.2.4 to 9.0.0.
Thanks for the reports! To help us understand the severity of this crash, can you let us know how often it's happening?
The error "An OAuth redirect was sent to a OIDExternalUserAgentSession after it already completed" suggests there could be some race condition where our handleURL: method is called multiple times for the same sign-in attempt. This appears to be an intermittent issue that is difficult to reproduce. I did take a look at our releases, but nothing strongly stuck out as the issue to me.
Any additional details about your project setup, especially other SDKs you are using that might also handle URL redirects, could be helpful.
@brnnmrls, it crashes often daily. Also, the only solution is to use 8.x SDK version instead of 9.x, which has this bug. Take a look into OpenID SDK as 9.x uses the OpenID 2.x version where 8.x uses a older version.
we met the same issue after migrating from 8.0.0 to 9.0.0.
Same issue after after migrating from 7.1.0 to 9.0.0
Can you please provide additional information on how/when you integrating with GSI are calling GIDSignIn handleURL.
If you are able to provide repro steps using the DaysUntilBirthday example app or a recording of it happening that would be ideal.
@camden-king If this help in understanding the crash - https://github.com/MaikuB/flutter_appauth/issues/552
After some investigation the team believes that this crash only happens when the sign-in is done in an external browser. However we also could not reproduce the issue by forcing a sign-in flow from an external browser (e.g. copying and pasting the URL into an external browser). To help us understand the issue better:
- Could you let us know how exactly the user is completing the sign-in flow? If there are repro steps, that would be great.
- To test this - are you able to force sign-in via an external browser from your apps by modifying the logic in AppAuth (if this is possible)?
To test this - are you able to force sign-in via an external browser from your apps by modifying the logic in AppAuth (if this is possible)?
@joannetsaii, I might not be able to test this, but it’s highly likely for enterprise customers using managed devices where SSO is only available via Microsoft Edge. 🫠
I don't know what exactly flow looks like, but I know such a use case exists and we received reports before about such limitations that users have on their phones.
We suspect this crash occurs when the sign-in flow falls back to an external browser after ASWebAuthenticationSession fails to open. We’ve had difficulty reproducing it consistently.
To help us debug, could you please set the following breakpoints in AppAuth's OIDExternalUserAgentIOS.m and share what you find?
- At the start of
presentAuthorizationRequest:session:. - On the
[_asWebAuthenticationSession start]call. - On the
return [self presentExternalUserAgentRequest:request session:session];line in theelseblock.
Please let us know which breakpoints are hit and in what order. Any details on variable values at those points would be very helpful. Thanks for your help
also experiencing this. Is there any workaround for this, other than downgrading?
I dont even know when exactly this happens, so I can't really help my users..
We are also experiencing this issue after migrating from 8.0.0 to 9.0.0.
Same issue after after migrating from 7.1.0 to 9.0.0
In our case whenever it happens, there's this error in the logs prior to the crash: Error Domain=com.google.GIDSignIn Code=-5 "The user canceled the sign-in flow." UserInfo={NSLocalizedDescription=The user canceled the sign-in flow. and then the user tries to sign in again.
Though we were not able to reproduce the crash.
@banaslee thank you very much for that log information. When you say "the user tries to sign in again" do you mean they click the sign in with Google button again/re-launch the webview or that the next event is that [GIDSignIn handleURL:] is called.
@camden-king that the user taps on the Google Sign in button again/tries to start the Google sign in flow again.
That's as much detail we can get from our logs
I was able to trigger this by rapidly tapping the google sign in button. This launches google sign in on both the internal and external browser. After completing the external one it crashes.
Our app is on React Native using the package react-native-google-signin by @vonovak. It was using the version 9.0.0 and we started seeing external browser redirects for google signin. Ideally it should be an in app browser intent. Upon signing in , the app crashes. The solution to downgrade to 8.0.0 pod doesnot work for us because it takes away the feature of providing custom nonce and we are dealing with on chain accounts and keyless accounts in Aptos which needs nonce to derive your. We are completely blocked on this. Any update about a possible fix or possible ways to handle this scenario ?
@Chiratna are you able to reproduce this yourself using a react native app? If so can you please provide repro steps and ideally a sample app.
Also is everyone experiencing this issue using a react native app or is it both react native and iOS implemented?
@camden-king we experienced this issue in production with our native iOS app. Have now reverted back to 8.x.x so no longer experience the crashes.
we experienced this issue in production with our native iOS app. Have now reverted back to 8.x.x so no longer experience the crashes.
@Chiratna are you able to reproduce this yourself using a react native app? If so can you please provide repro steps and ideally a sample app.
Also is everyone experiencing this issue using a react native app or is it both react native and iOS implemented?
We are using native iOS SDK.
We are seeing this crash in production for some time now in our native iOS app using v9.0.0 of the SDK. Any updates on whether this can be addressed and any ETA on the same?
@mdmathias @brnnmrls @camden-king request your help here with this production crash
Hello everyone,
Thank you for the detailed reports and patience as we investigated this issue.
We have been able to recreate this crash in two ways mentioned above:
- When the SiwG button is hit rapidly multiple times before the webview opens, the app will open the internal browser and external browser. The flow will crash on completion.
- Thank you @cltnschlosser for these repro steps.
- When the user manually opens the SiwG page in an external web browser. This flow will crash only if the ASWAS webview is closed after the page is opened in an external web browser (but before redirected back to the app).
- Thank you @balavor for these repro steps.
- This is not a recommended or supported flow.
We are planning to implement the following changes in GoogleSignIn-iOS and AppAuth-iOS to prevent crashes in the flows mentioned above.
- [AppAuth-iOS] Only support sign-ins through ASWAS.
- [AppAuth-iOS] Return errors instead of throwing exceptions in resumeExternalUserAgentFlowWithURL.
- [GoogleSignIn-iOS] Return errors in handleURL.
We plan to have a fix out sometime early in 2026. In the meantime we recommend wrapping -[GIDSignIn handleURL:] in a do/catch block. Lastly, we would welcome external contributions towards fixing this bug.
We are seeing this on our app as well for version 7.1.0 on users running the app on iPad OS 18.7.0 .