FirebaseUI for Web v7: authentication components for React, Shadcn and Angular

The boilerplate FirebaseUI for Web removes, and who still has to write it

Every Firebase Authentication integration starts the same way: an email and password form, a password reset flow, an email link handler, a phone number entry with reCAPTCHA, OAuth provider buttons, and increasingly a second-factor step. None of that is hard, and all of it is repeated in every project. FirebaseUI for Web exists to delete that repetition. The README describes it as "out-of-the-box components for Firebase", and lists the supported flows explicitly: Email/Password Sign Up/In, Forgot Password, Email Link, Phone Auth, OAuth, Multi-Factor and more.

The audience is narrow and easy to state. You are building a web app, you have already chosen Firebase Authentication as your identity provider, and you want the sign-in surface to look consistent across flows without maintaining it yourself. The README also lists built-in localization via translations, which matters if you ship in more than one language and would otherwise hand-write every string.

If your identity provider is not Firebase, this library has nothing to offer you. It is a UI layer over Firebase SDKs, not an abstraction over authentication in general.

How the core, the framework packages and the styles package fit together

The repository is a pnpm workspace, and the root package.json shows the shape of it. The build script runs, in order, @firebase-oss/ui-translations, @firebase-oss/ui-styles, @firebase-oss/ui-core, @firebase-oss/ui-react, @firebase-oss/ui-angular and @firebase-oss/ui-shadcn, then the example apps. That ordering is the dependency graph: translations and styles are leaves, core sits above them, and the framework packages sit above core.

The data flow is a single object. You call initializeUI with your configured Firebase App instance, and it returns a ui instance. That instance is handed to the framework binding, which is FirebaseUIProvider in React and a provideFirebaseUI provider in Angular. Components read from it. The README calls core "framework agnostic" and offers a bring-your-own-UI path, so the same ui instance can drive components you write yourself.

Behavior is configured through what the README calls behaviors, which the project describes as the way to configure the internal logic and UI. The README does not spell out the behavior API in the section shown, so treat that as something to read in the reference API before you commit to a customization plan. The separation between core and framework packages is the part worth noting: it means a React app and an Angular app in the same organization can share the same authentication behavior configuration rather than reimplementing it.

Installing FirebaseUI for Web and rendering a first sign-in screen in React

The README requires the firebase package first, then the framework-specific package. For React that is @firebase-oss/ui-react.

npm install firebase
npm install @firebase-oss/ui-react

Next you initialize Firebase as usual and pass the app into initializeUI, which comes from the core package.

import { initializeApp } from 'firebase/app';
import { initializeUI } from '@firebase-oss/ui-core';

const app = initializeApp({ ... });

const ui = initializeUI({
  app,
});

Wrap your application in FirebaseUIProvider and pass the ui instance. The README shows this at the root of the component tree.

import { FirebaseUIProvider } from '@firebase-oss/ui-react';

function App() {
  return (
    <FirebaseUIProvider ui={ui}>
      ...
    </FirebaseUIProvider>
  );
}

The README states that you must also import the bundled styles. With a bundler that supports CSS imports, that is a single import; Tailwind users get a separate entry point.

@import "@firebase-oss/ui-styles/dist.min.css";
/* Or, if you use tailwind */
@import "@firebase-oss/ui-styles/tailwind";

After that, SignInAuthScreen from @firebase-oss/ui-react renders the full flow. The README's example passes an onSignIn callback, which is where you redirect or update application state. If you skip the stylesheet import, expect an unstyled form rather than an error.

Shadcn and Angular take different installation routes

The Shadcn path does not install a component package for the screen itself. You add the @firebase registry to components.json, then pull the component from that registry.

{
  "registries": {
    "@firebase": "https://firebaseopensource.com/r/{name}.json"
  }
}

npx shadcn@latest add @firebase/sign-in-auth-screen

The README states that this automatically installs required dependencies, and that the component is then imported from your local components directory rather than from a package. It also states that the styling section does not apply to Shadcn projects, because styles are inherited from your Shadcn configuration. That is a meaningful difference: a Shadcn project gets a copy of the component it can edit, at the cost of tracking upstream changes manually.

The Angular path has a prerequisite the other two do not. The README says the Angular project requires AngularFire to be set up and configured first, and that you provide the Firebase App instance via provideFirebaseApp. The install line pulls four packages at once, including @angular/fire. The provider is provideFirebaseUI, which receives the apps array and returns initializeUI({ app: apps[0] }). The component selector in the README example is fui-sign-in-auth-screen.

The v6 rewrite is the biggest cost of adopting FirebaseUI for Web v7

The README opens the migration section with a blunt sentence: v7 is a complete rewrite to support modern languages and frameworks. The previous version lives on the v6-archive branch, and the project points readers to MIGRATION.md. That is the honest description of the situation, and it should shape your decision more than any feature list.

If you have an existing v6 integration, upgrading is not a version bump. The package names changed from whatever v6 used to the @firebase-oss/ui-* family, the entry point changed to initializeUI plus a framework provider, and the styling import is new. Anything you customized in v6 needs to be re-expressed as a behavior or as your own component on the core package. The README does not document a compatibility shim or a rollback path, so plan the migration as a branch you can abandon.

There is a second limitation that follows from the architecture. The framework packages are React, Shadcn and Angular. If you are on Vue, Svelte or a server-rendered framework without one of those bindings, you are on the bring-your-own-UI path, which means writing the components yourself against the core package. That is a legitimate use of the library, but it is a different amount of work than the README's first example suggests.

FirebaseUI for Web compared with the Firebase JS SDK on its own

The real alternative is not another UI library. It is the Firebase JS SDK directly. With the SDK alone you call signInWithEmailAndPassword, sendPasswordResetEmail, signInWithPhoneNumber and the OAuth provider helpers, and you build every form, every error message and every loading state yourself.

The difference in approach is where the state lives. With the raw SDK, your component owns the form state, the pending state and the error mapping, and you decide how a wrong password is displayed. FirebaseUI for Web moves that into the ui instance and the behaviors that configure it, and gives you a component that already knows how to render each flow. You trade control over markup and error presentation for not writing it.

The choice usually comes down to how much of the sign-in experience is part of your product's identity. A consumer app with a heavily designed onboarding screen will fight a prebuilt component. An internal tool or a project where sign-in is a means to an end is a better fit. Note that localization is listed as built in, which is a concrete reason to prefer the library over hand-rolled forms if you ship in several languages.

Licence, maintenance and what upgrading actually costs

The repository is licensed Apache-2.0, the same licence family as much of the Firebase tooling. That permits commercial use and modification, and it includes a patent grant, but it also carries notice and attribution obligations for distributed copies. Read LICENSE in the repository rather than relying on a summary, and involve your own counsel if you redistribute the components as part of a product.

The maintenance picture is current. The last push to the default branch was on 2026-09-22, and the most recent release listed is v7.1.0 from 2026-08-12, preceded by v7.0.3 on 2026-07-23. The repository is not archived. That matters for a dependency that sits on your login screen, where an abandoned library becomes a security problem rather than a cosmetic one.

Upgrade cost is the part to budget for. The workspace publishes several packages with their own versions, and the Shadcn route copies component source into your project, so upstream fixes do not reach you until you re-run the registry command. The e2e directory and the examples directory (react, nextjs, nextjs-ssr, angular, shadcn, custom-auth-server) are the places to look when a behavior does not do what you expect, because the README's shown section stops before the reference API.

What to check before you commit to FirebaseUI for Web

Verify three things in order. First, confirm that Firebase Authentication is genuinely your backend and that the flows you need are in the list the README gives: Email/Password, Forgot Password, Email Link, Phone Auth, OAuth, Multi-Factor. If you need a flow outside that list, the core package plus your own UI is the path, and you should price that work honestly.

Second, if you are on v6, read MIGRATION.md before writing any code. The rewrite means the migration is a real project, and the absence of a documented rollback in the README means your fallback is the v6-archive branch.

Third, run one of the examples rather than starting from a blank project. The repository ships examples for react, nextjs, nextjs-ssr, angular, shadcn and custom-auth-server, and the root package.json wires a Firebase Auth emulator command for local work. Starting from the example closest to your stack will surface the styling import and the provider wiring, which are the two steps people skip.

Editorial conclusion

Adopt FirebaseUI for Web if your app already runs on Firebase Authentication and you want Email/Password, Email Link, Phone Auth, OAuth and Multi-Factor screens without writing them yourself. Do not adopt it if you need a non-Firebase identity provider, or if you are on the v6 API and cannot absorb a rewrite right now. Before starting, read MIGRATION.md, confirm the exact package names for your framework, and check the examples/ directory for the closest match to your setup.

Frequently asked questions

Official sources

1. firebase/firebaseui-web on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases