Emne: Login og adgang

Firebase Authentication som login i en AI-bygget app

Firebase Authentication kan håndtere brugerkonti og login uden, at I selv skal gemme adgangskoder. Men et fungerende login beskytter ikke automatisk appens data. Denne guide viser både den tekniske opsætning og den adgangskontrol, der skal følge med.

Opdateret 31. juli 2026 · Ca. 12 minutters læsetid

Hvad er Firebase?

Firebase er Googles platform med blandt andet hosting, databaser, fillagring, serverfunktioner og brugerlogin. I behøver ikke bruge alle delene. En eksisterende app kan godt bruge Firebase Authentication til login og have data eller hosting et andet sted.

Firebase project
Beholderen for appens Firebase-tjenester, brugere og indstillinger.
Authentication
Bekræfter hvem brugeren er og giver hver bruger et unikt UID.
Firestore
En dokumentdatabase, som ofte bruges direkte fra webappen.
Security Rules
Serverhåndhævede regler for hvilke data en bruger må læse og ændre.

Login og adgang er ikke det samme

Authentication svarer på: Hvem er brugeren?Adgangskontrol svarer på: Hvad må brugeren se og gøre?Hvis appen kun skjuler en side i brugerfladen, kan en teknisk bruger stadig forsøge at kalde databasen eller API'et direkte.

Et loginvindue er ikke en sikkerhedsmur. Beskyt Firestore og Storage med Security Rules, og kontrollér brugerens Firebase ID-token på jeres egen backend. Stol aldrig alene på en knap, en skjult rute eller en rolle gemt i browseren.

1. Opret de rigtige Firebase-projekter

Opret mindst ét projekt til udvikling og ét til produktion, før rigtige brugere og kundedata kommer ind. Det reducerer risikoen for, at en test rydder produktionsdata, sender mails til kunder eller ændrer produktionsregler.

  1. 1. Opret et udviklingsprojekt i Firebase Console.
  2. 2. Registrer webappen og kopier dens Firebase-konfiguration.
  3. 3. Opret et separat produktionsprojekt med sin egen konfiguration.
  4. 4. Begræns hvem der er ejer og redaktør af hvert projekt.
  5. 5. Dokumenter hvilket GitHub-repository og miljø der hører til hvert projekt.

Firebase-webkonfigurationen indeholder blandt andet et API key-felt, men fungerer som identifikation af projektet i klientappen og kan ses i browseren. Den er ikke en erstatning for Security Rules. Servicekontonøgler og Admin SDK-legitimationsoplysninger er derimod hemmelige og må aldrig ligge i frontendkoden eller GitHub.

2. Slå en loginmetode til

Åbn Authentication i Firebase Console, vælg Sign-in method, og aktivér den metode, appen skal bruge. Email og adgangskode er let at forstå, men kræver også nulstilling, mailbekræftelse og en fornuftig proces for oprettelse og lukning af brugere.

  • Intern app: Overvej at lade en administrator oprette eller invitere brugere frem for åben tilmelding.
  • Kundeportal: Planlæg registrering, mailbekræftelse, nulstilling og sletning som samlede brugerflows.
  • Virksomhedslogin: Google eller Microsoft kan være bedre, hvis brugerne allerede har administrerede arbejdskonti.

Ved email/adgangskode anbefaler Firebase at slå beskyttelse mod email enumeration til. Vis samtidig neutrale fejlbeskeder, så loginformularen ikke afslører, om en bestemt email findes i systemet.

3. Installer og initialiser Firebase Auth

Installer Firebase SDK'et med npm install firebase. Saml initialiseringen ét sted, og lad resten af appen importere de samme instanser. Eksemplet bruger Firebase's modulære web-API.

src/firebase/auth.js
import { initializeApp } from "firebase/app";
import {
  getAuth,
  onAuthStateChanged,
  signInWithEmailAndPassword,
  signOut,
} from "firebase/auth";

const app = initializeApp(firebaseConfig);
export const auth = getAuth(app);

export function watchLogin(callback) {
  return onAuthStateChanged(auth, callback);
}

export function logIn(email, password) {
  return signInWithEmailAndPassword(auth, email, password);
}

export function logOut() {
  return signOut(auth);
}

Brug onAuthStateChangedsom kilde til loginstatus. Et direkte opslag icurrentUserkan være null, mens Firebase stadig gendanner en tidligere session.

4. Beskyt data med Security Rules

Start med lukket adgang, og åbn kun de konkrete stier og handlinger, appen behøver. Reglen her viser princippet for brugerdata i Firestore: En bruger må kun læse og skrive dokumentet med sit eget UID. Alt andet er lukket.

firestore.rules
rules_version = "2";
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null
                         && request.auth.uid == userId;
    }

    match /{document=**} {
      allow read, write: if false;
    }
  }
}

En regel som request.auth != nullbetyder kun “alle, der er logget ind”. Den adskiller ikke medarbejdere, kunder, virksomheder eller administratorer. Flerbrugerapps kræver normalt ejerskab, medlemskab eller roller i datamodellen og regler, som kontrollerer dem.

5. Test hele adgangsforløbet

Test ikke kun, at den rigtige bruger kan logge ind. De vigtigste sikkerhedstests kontrollerer, at en forkert eller udlogget bruger bliver afvist.

  • □ En gyldig bruger kan logge ind og bliver på den ønskede side efter genindlæsning.
  • □ Forkerte oplysninger giver en neutral og forståelig fejl.
  • □ En udlogget bruger kan ikke læse data ved direkte databasekald.
  • □ Bruger A kan ikke læse eller ændre bruger B's dokumenter.
  • □ Nulstilling og mailbekræftelse fører tilbage til det rigtige domæne.
  • □ Logout fjerner adgang, også hvis en beskyttet URL åbnes direkte bagefter.
  • □ Reglerne testes lokalt i Emulator Suite og i CI før deployment.

Typiske fejl i AI-byggede apps

  • Test Mode bliver stående: Databasen er åben i en periode eller for alle.
  • Login beskytter kun routen: Data kan stadig kaldes direkte.
  • Alle brugere får samme adgang: Reglerne kontrollerer login, men ikke ejerskab eller virksomhed.
  • Udvikling og produktion deler projekt: Testbrugere og kundedata blandes sammen.
  • Admin SDK havner i browseren: En hemmelig nøgle eller privilegeret serverkode bliver bundlet i frontend.
  • Kun det gode flow testes: Ingen har forsøgt at læse en anden brugers data eller bruge et udløbet token.

Tjekliste før andre får adgang

  • □ Udvikling og produktion bruger separate Firebase-projekter.
  • □ Projektroller og faktureringsadgang er begrænset til de rette personer.
  • □ Loginmetode, nulstilling, mailbekræftelse og logout er afprøvet.
  • □ Appen reagerer på loginstatus gennem en auth observer.
  • □ Firestore, Storage og backend har hver sin serverhåndhævede adgangskontrol.
  • □ Reglerne kontrollerer ejerskab eller rolle, ikke kun om brugeren er logget ind.
  • □ Ingen servicekontonøgler eller Admin SDK-secrets findes i frontend eller GitHub.
  • □ Emulator- og CI-tests dokumenterer både tilladt og afvist adgang.

Relaterede login- og Firebase-guides

Hvis medarbejderne allerede har administrerede Microsoft-konti, kan Microsoft Entra ID være et bedre virksomhedslogin. Hvis appen også bruger Firebase Hosting eller Cloud Firestore, beskriver den anden guide deployment, datamodel og backup.

Officielle kilder

Firebase ændrer løbende konsollen, SDK'et og sikkerhedsanbefalingerne. Kontrollér de aktuelle trin i Googles egen dokumentation, når I implementerer løsningen.