How to Implement Azure AD SSO for Firebase Apps

Integrating Microsoft Entra ID (formerly Azure Active Directory) with Firebase Authentication allows organizations to centralize identity management while leveraging Firebase’s mobile and web backend services. By configuring OpenID Connect (OIDC) as a custom authentication provider in the Firebase console, developers can enable Single Sign-On (SSO) for their applications, ensuring users authenticate against an enterprise-grade identity provider rather than managing separate credentials.

Configuring Entra ID as an OIDC Provider

To establish trust between Microsoft’s identity ecosystem and Firebase, you must first register an application within the Microsoft Entra admin center.

1. App Registration: Navigate to "App registrations" and create a new registration. Ensure the redirect URI matches the pattern provided by Firebase Authentication, typically formatted as https://<your-project-id>.firebaseapp.com/__/auth/handler.
2. Client Credentials: Generate a client secret in the "Certificates & secrets" section. Save this securely, as it is required to link the two services.
3. Endpoints: Locate the OpenID Connect metadata document URL under the "Endpoints" tab. This URL contains the necessary configuration data, including the issuer, authorization endpoint, and token endpoint, which Firebase needs to validate identity tokens.

Linking Firebase to Microsoft Entra

Once the Entra ID application is registered, you must configure the Firebase project to recognize it.

• Firebase Console: Open the Firebase console and navigate to the Authentication section.
• Sign-in Methods: Select Add new provider and choose OIDC.
• Provider Configuration: Input the Client ID and Client Secret generated from the Entra portal. Paste the Issuer URL from the OIDC metadata document.
• Scope Definition: Ensure the openid, profile, and email scopes are requested to retrieve the necessary user claims for the Firebase user record.

According to Google’s Firebase documentation, once this configuration is saved, Firebase generates a unique redirect URI. You must copy this URI back into the Entra ID application registration under the "Authentication" settings to complete the handshake.

Handling Authentication Flows in Client Applications

After the backend configuration is complete, client-side implementation involves triggering the OIDC sign-in flow. Developers use the Firebase Authentication SDK to initiate the process by creating an OAuthProvider instance.

javascript
import { getAuth, signInWithRedirect, OAuthProvider } from "firebase/auth";

const provider = new OAuthProvider(‘oidc.provider-id’);
const auth = getAuth();

signInWithRedirect(auth, provider);

When the user triggers this function, the SDK redirects them to the Microsoft login page. Upon successful authentication, Microsoft returns an ID token to the Firebase handler, which then exchanges it for a Firebase Auth token. This token grants the user access to Firebase services, such as Cloud Firestore or Realtime Database, while maintaining the security policies—such as Multi-Factor Authentication (MFA) or Conditional Access—defined in Entra ID.

Security Considerations and Best Practices

Implementing SSO between these platforms requires careful management of identity tokens.

• Token Validation: Firebase automatically validates the ID token signature against the public keys provided by the Microsoft OIDC discovery document.
• User Mapping: Since Entra ID and Firebase may treat user identifiers differently, ensure your application logic handles the sub (subject) claim from the ID token as the primary unique identifier.
• Conditional Access: Because the authentication occurs at the Microsoft level, any Conditional Access policies applied to the Entra application—such as requiring managed devices or specific IP ranges—will be enforced before the user ever reaches the Firebase application.

By offloading authentication to Entra ID, teams reduce the attack surface of their Firebase apps by eliminating the need to store local user credentials, relying instead on Microsoft’s robust infrastructure to manage identity lifecycles.