एउटा REST API सुरक्षित गर्नु भनेको हरेक request मा तीन प्रश्नको जवाफ दिनु हो: तिमी को हौ (authentication), तिमीलाई के गर्न अनुमति छ (authorization), र channel निजी छ कि (transport)। REST stateless हुने हुनाले, credential server session मा बस्नुको सट्टा हरेक request सँग यात्रा गर्नुपर्छ।
तल सबै कुराले मानेको छ। यसबिना, token र API key plaintext मा यात्रा गर्छन् र sniff गर्न सकिन्छ। यो गैर-सम्झौतायोग्य छ — HTTP माथिको bearer token एउटा leak भएको token हो।
API key — एउटा header मा static secret। सरल; server-to-server र एउटा user होइन एउटा application पहिचान गर्न राम्रो। आफैंमा कमजोर (expiry छैन, scope छैन) जबसम्म थपसँग जोडिँदैन।
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
OAuth 2.0 — delegated access ("App X लाई मेरो password बिना मेरो data पढ्न देऊ") का लागि standard। App ले एउटा flow (जस्तै Authorization Code) मार्फत एउटा access token प्राप्त गर्छ र यसलाई bearer token का रूपमा पठाउँछ। "Sign in with Google" र third-party integration यसरी काम गर्छन्।
JWT (JSON Web Token) — token का लागि एउटा सामान्य format: claim (user id, role, expiry) बोक्ने एउटा signed, आत्म-निहित token। Server ले signature प्रमाणित गर्छ — कुनै database lookup चाहिँदैन, जुन stateless REST सँग मिल्छ।
header.payload.signature (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
Authentication ले पहिचान प्रमाणित गर्छ; authorization ले access निर्णय गर्छ। Token हरूले scope (orders:read, orders:write) वा role बोक्छन्; server ले तिनलाई प्रति endpoint जाँच्छ र अपर्याप्त हुँदा 403 Forbidden फर्काउँछ (auth हराएको/अवैध हुँदा 401 को विपरीत)।
No/invalid token → 401 Unauthorized
Valid token, no scope → 403 Forbidden
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
Security त्यो ठाउँ हो जहाँ एउटा सानो गल्ती breach बन्छ, त्यसैले interviewer हरूले यसलाई तपाईं buzzword रटाउनुभन्दा संरचनात्मक रूपमा तर्क गर्नुहुन्छ कि भनेर हेर्न प्रयोग गर्छन्। तिनले खोज्ने सङ्केत भनेको तपाईंले तीन तह छुट्याउनुहुन्छ — transport (HTTPS, सधैं), authentication (bearer token/JWT/OAuth मार्फत, stateless रूपमा पहिचान प्रमाणित गर्ने), र authorization (scope र least privilege) — र तपाईं तिनलाई मिसाउनुहुन्न, जस्तै "authenticate नभएको" का लागि 401 र "authenticate भएको तर अनुमति नभएको" का लागि 403 सही प्रयोग गर्ने। बलिया जवाफहरूले व्यावहारिक trade-off को जागरूकता देखाउँछन्: JWT सुविधाजनक र stateless छन् तर expire हुनुअघि revoke गर्न गाह्रो (त्यसैले छोटो जीवनकाल र refresh token), API key ले user होइन app पहिचान गर्छन्, र OAuth ठ्याक्कै यसैका लागि छ ताकि user ले आफ्नो password third party लाई नदिऊन्। यसलाई REST को statelessness सँग जोड्नु — हरेक request मा credential, कुनै server session छैन — ले तपाईं API security यस्तो किन देखिन्छ भन्ने बुझ्नुहुन्छ भन्ने देखाउँछ।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्