You’re right to be confused — Google’s Identity Platform (especially when using Google Identity Platform / Firebase Authentication / Google Cloud Identity) can be deceptively simple, but under the hood it lacks some flexibility compared to full-fledged Identity Providers (IdPs) like Keycloak or Auth0.
Here’s what’s going on and why it’s behaving differently from what you’re used to:
What’s the Root of the Issue?
1. Google’s “Default Auth” Flow Is Not a Full IdP in the Traditional Sense
When you configure Google as an OpenID Connect (OIDC) provider (e.g., for Discourse), you’re usually just using Google Sign-In — that is, users logging in with their Google account.
But Google’s Identity Platform doesn’t expose other identity providers (like Apple, email/password, etc.) via OIDC to third-party relying parties — unless you build a custom login UI that manages the flow.
2. No Central Login Mask / Unified Login Page
Unlike Keycloak or Auth0, Google’s identity system does not provide a hosted, pluggable login screen that shows all available identity providers (Apple, Google, Email, etc.) on behalf of another service via a standard redirect-based flow (like /auth/realms/foo/protocol/openid-connect/auth in Keycloak).
This means when you configure additional providers (Apple, GitHub, email/password, etc.) in Firebase or Google Cloud Identity, users won’t see them unless you build your own UI (or use FirebaseUI).
What You Can Do
Option 1: Use FirebaseUI Hosted Auth Page
FirebaseUI can show a combined login screen with all your configured providers (Google, Apple, Email, etc.), but it requires you to host a frontend.
You can then act as a pass-through IdP that:
- Accepts the user login using FirebaseUI
- Gets a Firebase ID token (or OAuth2 token)
- Exchanges that for a session in your Discourse instance (e.g., via Discourse API)
But: this means you can’t just use the Discourse OIDC plugin with Google’s OIDC endpoint, since it doesn’t handle the multi-provider flow for you.
Option 2: Use Auth0 or Keycloak as a Meta-Provider
Since both Auth0 and Keycloak can act as OIDC providers, you can configure them to:
- Use Google (via OAuth2)
- Use Apple
- Use email/password
- Show a combined login UI
Then configure Discourse to use Auth0 or Keycloak via the Discourse OIDC plugin.
This is what you’re likely already doing and might be the easiest way to get back to what you want.
Option 3: Custom Authentication Gateway
You could build your own lightweight login service that:
- Shows all your desired identity providers
- Handles auth with Firebase/Auth0/etc.
- Signs a JWT or SSO payload to send to Discourse via Discourse’s SSO interface
This is more complex and only worth doing if you need full control.
What’s Not Possible
- You can’t redirect to a Google-managed page that shows Apple, email, etc., and then bounces back to Discourse as a simple OIDC login.
- Google does not offer a multi-provider hosted login page under their OIDC endpoint.
Recommendation
Stick with Auth0 or Keycloak as your identity frontend, and use Google as a backend provider if needed. Let those handle:
- Multiple providers
- Unified login UI
- User session management
Then connect Discourse to your frontend IdP using the Discourse OIDC plugin — that way the experience stays consistent and robust.