Yes, please.

Hi team, can we get this prioritised please? As per this notification from Google:

We’re writing to let you know that end users of applications using Google Cloud Identity Platform may not be able to authenticate if you're using the signInWithRedirect method and your users are using one of the following browsers:

• Safari 16.1+ on macOS
• iOS 16.1+
• Firefox 109+

What do you need to know?
Based on our records, you have an app that uses signInWithRedirect in the Web SDK API, meaning your users who use the platforms listed above are impacted.

What do you need to do?
While we cannot control the version/settings of the browser sending the login request, we want to offer mitigations for > authentication in your app to continue working for all users. Please follow our GCIP best practices guide to make sure users can use your app when additional browser platform updates are released.

However all feasible options require setting the authDomain which is impossible to do on mobile.

I opened a ticket for Android as well.

Hi team, can we get this prioritised please? As per this notification from Google:

We’re writing to let you know that end users of applications using Google Cloud Identity Platform may not be able to authenticate if you're using the signInWithRedirect method and your users are using one of the following browsers:

• Safari 16.1+ on macOS
• iOS 16.1+
• Firefox 109+

What do you need to know?
Based on our records, you have an app that uses signInWithRedirect in the Web SDK API, meaning your users who use the platforms listed above are impacted.
What do you need to do?
While we cannot control the version/settings of the browser sending the login request, we want to offer mitigations for > authentication in your app to continue working for all users. Please follow our GCIP best practices guide to make sure users can use your app when additional browser platform updates are released.

However all feasible options require setting the authDomain which is impossible to do on mobile.

Thanks for filing this! The best practice needs to be applied only for web applications that use the signInWithRedirect web SDK API. No action is needed for mobile apps.

@prameshj thats great! Can you please elaborate why and explain what the best practice solution is for using a custom domain on mobile clients should then be?

@prameshj thats great! Can you please elaborate why and explain what the best practice solution is for using a custom domain on mobile clients should then be?

This guide applies to web applications that use redirect to login. The clients of this web app can be mobile clients (using a mobile browser) or web clients. The best practice(of setting authDomain or any other option) should be implemented in the web application.

This is needed because in redirect flow we 1) start at the app domain (call it domain1), 2) redirect to oauth helper code (in /__/auth/handler, call this domain 3), store some state in session storage of domain 2 3) redirect back to the app and open iframe to domain 2 and access session storage.

This cross origin storage access is disallowed in some browser policies, so all the best practices are towards making sure domain1 and domain2 are the same origin.

On mobile apps, a similar IDP sign in redirects to the browser, but there is no cross-origin storage access. Hence there is no action needed for mobile apps.

Similar to what I mentioned in the Android ticket, I guess our reasoning is not that it doesn't work, but that we would like to show our configured custom domain to the end user instead of the default *.firebaseapp.com domain for brand/trust reasons, during an OIDC or Microsoft login flow.

Is there a way to do this?

Hi @skion, we currently do not support custom domain on mobile. We have put this feature request on our radar, but we are unable to promise a timeline right now.

Similar to what I mentioned in the Android ticket, I guess our reasoning is not that it doesn't work, but that we would like to show our configured custom domain to the end user instead of the default *.firebaseapp.com domain for brand/trust reasons, during an OIDC or Microsoft login flow.

Is there a way to do this?

just a FYI - we dumped firebase and went with auth0; the lack of feature parity and prioritization for things like this was the motivator for moving off firebase auth.

At least indicate in the official documentation that using a custom domain leads to the breakdown of any oauth2 authorization in native applications (tested on github, apple, facebook).

Allowing the authDomain to be set in mobile is a must to prevent brute force attacks using the public key. This would allow us to host a proxy behind firewalls and WAF's that can mitigate such brute force attacks from hitting the google auth api's directly.