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

તમે કોણ છો, અને તમે આ કરી શકો?

FestConnect ને ખબર હોવી જોઈએ કે દરેક વપરાશકર્તા કોણ છે (authentication), અને જે કામ અમુક વપરાશકર્તાઓ જ કરી શકે એમને સાચવવાં પણ પડે. સલામત login જાતે બનાવવું, એટલે કે passwords ને hash કરવા અને sessions સંભાળવાં, અઘરું છે અને એમાં ખતરનાક ભૂલ થવી સહેલી છે. એટલે FestConnect એ કામ Firebase Authentication ને સોંપે છે.

Firebase નોંધણી અને login સંભાળે છે; સફળ થાય ત્યારે એ app ને એવો token આપે છે જે વપરાશકર્તા કોણ છે તે સાબિત કરે છે. Angular નું front end એ token requests સાથે મોકલે છે, અને Express નું backend સાચવેલાં કામ કરવા દેતાં પહેલાં એને verify કરે છે. આ છેલ્લો પાઠ એ જ પ્રવાહ સમજાવે છે, જે app ની સલામતીની કરોડરજ્જુ છે.

📖 Theory

Firebase Auth અને token (JWT)

Firebase Authentication તૈયાર નોંધણી અને login આપે છે (બીજી રીતો ઉપરાંત email અને password પણ), એટલે તમે કાચા passwords કદી જાતે સાચવતા નથી, એ કામ Firebase સલામત રીતે કરે છે.

વપરાશકર્તા log in કરે ત્યારે Firebase client ને ID token આપે છે, જે JWT (JSON Web Token) છે: નાનકડો, સહી કરેલો token, જે વપરાશકર્તાની ઓળખ સાથે લઈને ફરે છે. એના પર એવી ગુપ્ત ચાવીથી સહી થયેલી હોય છે જેના પર ફક્ત Firebase અને તમારો server ભરોસો કરે છે, એટલે એને પકડાયા વગર બનાવટી બનાવી કે બદલી શકાતો નથી. Angular app ને login વખતે આ token મળે છે અને એ દરેક request સાથે એને મોકલીને વપરાશકર્તાની ઓળખ સાબિત કરે છે. JWT ને એવા ઓળખપત્ર જેવો ગણો જેમાં છેડછાડ થઈ શકતી નથી અને જે વપરાશકર્તા login પછી સાથે રાખે છે.

⌨️ Practical

Angular: register કરવું, log in કરવું અને 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: protected route પીરસતાં પહેલાં token verify કરવો

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

Client પર કદી ભરોસો નહીં; ખાતરી હંમેશા server પર

અહીં સલામતીનો સોનેરી નિયમ આ છે: front end કંઈ પણ દાવો કરી શકે છે, એટલે server એ ખાતરી કરવી પડે. Browser માં જે ચાલે છે એ કોઈ પણ બદલી શકે છે, એટલે 'હું admin છું' એવું કહેતા request નો કશો અર્થ નથી, જ્યાં સુધી server token તપાસે નહીં.

Express ની બાજુએ Firebase Admin SDK બરાબર એ જ કરે છે: verifyIdToken(token) protected route ચાલે એ પહેલાં ગણિતની રીતે ખાતરી કરે છે કે token અસલી છે અને એની મુદત પૂરી થઈ નથી. Token ન હોય કે ખોટો હોય તો request નકારાય છે (401). UI માં button છુપાવવું એ સલામતી નથી; server પર token verify કરવું એ સલામતી છે. દરેક protected route ને આ જ રીતે સાચવો.

🧩 Quiz

વપરાશકર્તા Firebase દ્વારા log in કરે એ પછી, Express backend ને કઈ રીતે ખબર પડે કે protected route પરનું request ખરેખર પ્રમાણિત વપરાશકર્તા તરફથી જ આવ્યું છે?

1. Angular app request માં જે દાવો કરે એના પર એ ભરોસો કરી લે છે
2. એ request સાથે આવેલા ID token (JWT) ને Firebase Admin SDK (verifyIdToken) વડે verify કરે છે; ખોટો token નકારાય છે
3. એ તપાસે છે કે UI માં button દેખાતું હતું કે નહીં
4. એને ખબર પડી જ ન શકે; દરેક request ને પ્રવેશ મળે છે

💭 Think first

ભરોસાપાત્ર ન હોય એવા browser માંથી પસાર થતો સહી કરેલો JWT કેમ ભરોસાપાત્ર ગણાય?

Token વપરાશકર્તાના browser માંથી પસાર થાય છે, જેમાં છેડછાડ થઈ શકે છે. તો પણ server એના પર ભરોસો કેમ કરી શકે? વિચારીને પછી tap કરો.

✅ Summary

Key takeaways

• Firebase Authentication વપરાશકર્તાની નોંધણી અને login સંભાળે છે (email અને password ઉપરાંત બીજી રીતો પણ), એટલે passwords તમારે જાતે સાચવવા પડતા નથી.
• Login વખતે Firebase client ને ID token આપે છે, જે વપરાશકર્તાની ઓળખ સાથે લઈને ફરતો સહી કરેલો JWT છે.
• Angular નું front end એ token requests સાથે મોકલે છે (Authorization: Bearer <token>), જેથી વપરાશકર્તા કોણ છે તે સાબિત થાય.
• Express નું backend protected route પીરસતાં પહેલાં Firebase Admin SDK (verifyIdToken) વડે token verify કરે છે; ખોટો હોય તો 401.
• સોનેરી નિયમ: client ના દાવા પર કદી ભરોસો ન કરો; ખાતરી હંમેશા server પર કરો.
• ભરોસાપાત્ર ન હોય એવા browser માંથી પસાર થતો સહી કરેલો JWT એટલા માટે ભરોસાપાત્ર છે કે છેડછાડથી એની સહી તૂટે છે અને ખાતરી (તથા મુદતની તપાસ) એને પકડી પાડે છે.
• યાદ રાખવાની કડી: Firebase વપરાશકર્તાઓને log in કરાવે છે અને JWT આપે છે; server request પર ભરોસો કરતાં પહેલાં એને verify કરે છે.