Authentication and Security Basics: Firebase Authentication (Email & Password); user registration and login to Angular frontend; securing backend routes with Firebase Admin SDK and JWT

📖 Theory

Who are you, and can you do this?

FestConnect must know who each user is (authentication) and protect actions only certain users may take. Building secure login yourself, hashing passwords, managing sessions, is hard and easy to get dangerously wrong. So FestConnect uses Firebase Authentication to handle it.

Firebase manages sign-up and login; on success it hands the app a token proving who the user is. The Angular front end sends that token with requests, and the Express backend verifies it before allowing protected actions. This closing lesson covers that flow, the security backbone of the app.

📖 Theory

Firebase Auth and the token (a JWT)

Firebase Authentication provides ready-made sign-up and login (email and password, among others), so you never store raw passwords yourself, Firebase does it securely.

When a user logs in, Firebase issues the client an ID token, which is a JWT (JSON Web Token): a compact, signed token that carries the user's identity. Because it is signed with a secret only Firebase and your server trust, it cannot be forged or tampered with without detection. The Angular app receives this token on login and will send it along with each request to prove the user's identity. Think of the JWT as a tamper-proof ID card the user carries after logging in.

⌨️ Practical

Angular: register, log in, and send the token

// Using the Firebase Auth SDK in Angular
import { getAuth, createUserWithEmailAndPassword,
         signInWithEmailAndPassword } from 'firebase/auth';

const auth = getAuth();
// register
await createUserWithEmailAndPassword(auth, email, password);
// login
const cred = await signInWithEmailAndPassword(auth, email, password);
const token = await cred.user.getIdToken();   // the JWT

// send it with an API request so the server can verify who you are:
this.http.get('/api/profile', {
  headers: { Authorization: `Bearer ${token}` },
}).subscribe(/* ... */);

⌨️ Practical

Express: verify the token before serving a protected route

const admin = require('firebase-admin');   // Firebase Admin SDK

// middleware: verify the token, or reject with 401
async function requireAuth(req, res, next) {
  const header = req.headers.authorization || '';
  const token = header.replace('Bearer ', '');
  try {
    req.user = await admin.auth().verifyIdToken(token);  // trust only if valid
    next();
  } catch {
    res.status(401).json({ error: 'Not authenticated' });
  }
}

app.get('/api/profile', requireAuth, (req, res) => res.json(req.user));

This example runs in Gri-Learn on the web, where you can edit it and see the output.

✏️ Formula

Never trust the client; always verify on the server

The golden rule of security here: the front end can claim anything, so the server must verify. Anyone can alter what runs in a browser, so a request saying 'I am the admin' means nothing until the server checks the token.

That is exactly what the Firebase Admin SDK does on the Express side: verifyIdToken(token) cryptographically confirms the token is genuine and unexpired before the protected route runs. A missing or invalid token is rejected (401). Hiding a button in the UI is not security; verifying the token on the server is. Guard every protected route this way.

🧩 Quiz

After a user logs in via Firebase, how does the Express backend know a request to a protected route really comes from that authenticated user?

1. It trusts whatever the Angular app claims in the request
2. It verifies the ID token (JWT) sent with the request using the Firebase Admin SDK (verifyIdToken); an invalid token is rejected
3. It checks whether the button was visible in the UI
4. It cannot know; any request is allowed

💭 Think first

Why is a signed JWT trustworthy when it travels through the untrusted browser?

The token passes through the user's browser, which could be tampered with. Why can the server still trust it? Then tap.

✅ Summary

Key takeaways

• Firebase Authentication handles user sign-up and login (email/password and more), so you do not store passwords yourself.
• On login, Firebase issues the client an ID token, which is a signed JWT carrying the user's identity.
• The Angular front end sends the token with requests (Authorization: Bearer <token>) to prove who the user is.
• The Express backend verifies the token with the Firebase Admin SDK (verifyIdToken) before serving a protected route; invalid means 401.
• The golden rule: never trust the client's claims; always verify on the server.
• A signed JWT is trustworthy through the untrusted browser because tampering breaks its signature and verification (and expiry) catches it.
• Memory hook: Firebase logs users in and issues a JWT; the server verifies it before trusting the request.