Theory
आप कौन हैं, और क्या आप यह कर सकते हैं?
FestConnect को जानना पड़ता है हर user कौन है (authentication) और सिर्फ़ कुछ users जो actions ले सकते हैं उन्हें protect करना पड़ता है। खुद secure login build करना, passwords hash करना, sessions manage करना, hard है और dangerously wrong होना easy है। तो FestConnect इसे handle करने के लिए Firebase Authentication इस्तेमाल करता है।
Firebase sign-up और login manage करता है; success पर यह app को एक token hand करता है यह prove करते हुए user कौन है। Angular front end requests के साथ वह token भेजता है, और Express backend protected actions allow करने से पहले इसे verify करता है। यह closing lesson उस flow को cover करता है, app की security backbone।
Theory
Firebase Auth और Token (एक JWT)
Firebase Authentication ready-made sign-up और login provide करता है (email और password, दूसरों के बीच), तो आप कभी खुद raw passwords store नहीं करते, Firebase इसे securely करता है।
जब एक user login करता है, Firebase client को एक ID token issue करता है, जो एक JWT (JSON Web Token) है: एक compact, signed token जो user की identity carry करता है। चूँकि यह एक secret से signed है जिस पर सिर्फ़ Firebase और आपका server trust करते हैं, यह detection के बिना forge या tamper नहीं हो सकता। Angular app login पर यह token receive करता है और हर request के साथ इसे भेजेगा user की identity prove करने के लिए। JWT को login के बाद user carry करने वाला एक tamper-proof ID card सोचिए।
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 Serve करने से पहले 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 पर कभी Trust मत कीजिए; हमेशा Server पर Verify कीजिए
यहाँ security का golden rule: front end कुछ भी claim कर सकता है, तो server को verify करना पड़ता है। कोई भी browser में क्या run होता है इसे alter कर सकता है, तो 'मैं admin हूँ' कहने वाली एक request का कोई मतलब नहीं जब तक server token check न करे।
यही exactly वह है जो Firebase Admin SDK Express side पर करता है: verifyIdToken(token) cryptographically confirm करता है token protected route चलने से पहले genuine और unexpired है। एक missing या invalid token reject (401) होता है। UI में एक button hide करना security नहीं है; server पर token verify करना है। हर protected route को इस तरह guard कीजिए।
Quiz
Firebase के through एक user login करने के बाद, Express backend कैसे जानता है एक protected route की request really उस authenticated user से आती है?
- यह जो भी Angular app request में claim करता है उस पर trust करता है
- यह Firebase Admin SDK (verifyIdToken) इस्तेमाल करके request के साथ भेजे गए ID token (JWT) को verify करता है; एक invalid token reject होता है
- यह check करता है button UI में visible था या नहीं
- यह जान नहीं सकता; कोई भी request allowed है
Show the answer
यह Firebase Admin SDK (verifyIdToken) इस्तेमाल करके request के साथ भेजे गए ID token (JWT) को verify करता है; एक invalid token reject होता है
Backend उस ID token (एक signed JWT) को verify करता है जो client request के साथ भेजता है, Firebase Admin SDK के verifyIdToken इस्तेमाल करते हुए, जो cryptographically confirm करता है token genuine है और user identify करता है; एक missing या invalid token 401 से reject होता है। Option A core rule violate करता है, client के claims पर कभी trust मत कीजिए, क्योंकि कोई भी एक request body forge कर सकता है, सिर्फ़ एक verified token identity prove करता है। Option C एक UI detail है, security नहीं: एक button hide करना किसी को directly request craft करने से नहीं रोकता, तो यह कुछ prove नहीं करता। Option D wrong है: token verification के साथ server absolutely establish कर सकता है (और करना चाहिए) कौन call कर रहा है। Server पर token verify कीजिए; client claims पर trust मत कीजिए।
Think first
Untrusted Browser के through Travel करने पर एक Signed JWT Trustworthy क्यों है?
Token user के browser से गुज़रता है, जो tampered with हो सकता है। Server अभी भी इस पर trust क्यों कर सकता है? फिर tap कीजिए।
Show the answer
क्योंकि JWT cryptographically SIGNED है, तो कोई भी tampering signature तोड़ देती है और server इसे detect करता है, token की trustworthiness maths से आती है, browser पर trust करने से नहीं। जब Firebase एक ID token issue करता है, यह token के contents (user कौन है, यह कब expire होता है) को एक secret key से sign करता है। Server, Firebase Admin SDK इस्तेमाल करते हुए, verifyIdToken के दौरान उस signature को Firebase की public keys के against check करता है। अगर token का एक character भी, मान लीजिए, user id को 'admin' में बदलना, browser में alter हुआ, signature अब (अब अलग) contents से match नहीं करता, और verification FAIL होता है, तो forged token reject हो जाता है। एक attacker altered contents के लिए एक valid signature produce नहीं कर सकता क्योंकि उनके पास secret signing key नहीं है; सिर्फ़ Firebase genuinely signed tokens create कर सकता है। यही वजह है token को untrusted browser के through travel करने और client से send होने देना safe है: server browser को honest होने के लिए trust नहीं कर रहा, यह mathematically verify कर रहा है token Firebase से issue हुआ था और change नहीं हुआ। Verification EXPIRY भी check करता है, तो old tokens काम करना बंद कर देते हैं, अगर एक leak होता है damage limit करते हुए। यही signed tokens का पूरा point है: trust cryptographic proof से established होता है, transport पर trust करने से नहीं। एक broken signature एक rejected request है, यही वजह है 'token verify कीजिए' real security है जबकि 'browser ने ऐसा कहा' नहीं है। Signatures token को tamper-evident बनाते हैं, तो server इस पर एक untrusted जगह से भी trust कर सकता है।
Summary
Key takeaways
- Firebase Authentication user sign-up और login handle करता है (email/password और ज़्यादा), तो आप खुद passwords store नहीं करते।
- Login पर, Firebase client को एक ID token issue करता है, जो user की identity carry करने वाला एक signed JWT है।
- Angular front end requests के साथ token भेजता है (Authorization: Bearer <token>) user कौन है यह prove करने के लिए।
- Express backend एक protected route serve करने से पहले Firebase Admin SDK (verifyIdToken) से token verify करता है; invalid का मतलब 401 है।
- Golden rule: client के claims पर कभी trust मत कीजिए; हमेशा server पर verify कीजिए।
- एक signed JWT untrusted browser के through trustworthy है क्योंकि tampering इसकी signature तोड़ती है और verification (और expiry) इसे catch करता है।
- Memory hook: Firebase users को login कराता है और एक JWT issue करता है; request पर trust करने से पहले server इसे verify करता है।