API Gateway authorizer चुनना

डेवलपर्स के लिए AWS Security का उपयोग

Rahul Singh

Technical Product Manager

आपके कोड चलने से पहले जाँच

आपके कोड तक पहुँचने से पहले कॉलर API Gateway authorizer से गुजरता है, और अस्वीकृत कॉलर को 401 के साथ लौटा दिया जाता है.

Pass: रिक्वेस्ट आपके कोड तक पहुँचती है

Fail: 401 unauthorized, आपका कोड नहीं चलता

जाँच कौन करता है

चुनने के लिए तीन authorizer

IAM auth (AWS_IAM): AWS सिग्नेचर जाँचता है

एक ऊर्ध्व स्टैक, ऊपर AWS जाँचता है से नीचे आप जाँचते हैं तक. अभी केवल पहला कार्ड भरा है: IAM auth, जहाँ AWS सिग्नेचर जाँचता है.

जाँच कौन करता है

चुनने के लिए तीन authorizer

IAM auth (AWS_IAM): AWS सिग्नेचर जाँचता है
Cognito authorizer (COGNITO_USER_POOLS): AWS टोकन वेरिफ़ाई करता है
- Signature, iss, aud, exp

वही ऊर्ध्व स्टैक, अब दो कार्ड भरे: IAM auth जहाँ AWS सिग्नेचर जाँचता है, और Cognito authorizer जहाँ AWS टोकन वेरिफ़ाई करता है.

जाँच कौन करता है

चुनने के लिए तीन authorizer

IAM auth (AWS_IAM): AWS सिग्नेचर जाँचता है
Cognito authorizer (COGNITO_USER_POOLS): AWS टोकन वेरिफ़ाई करता है
- Signature, iss, aud, exp
Lambda authorizer: आपका फंक्शन allow या deny लौटाता है
- गैर-Cognito टोकन के लिए

तीन authorizer, ऊपर AWS जाँचता है से नीचे आप जाँचते हैं तक: IAM auth में AWS सिग्नेचर जाँचता है, Cognito authorizer में AWS टोकन वेरिफ़ाई करता है, और Lambda authorizer में आप जाँच लिखते हैं.

दरवाज़ा कॉलर से मिलाएँ

कॉलर तय करता है

Internal service: पहले से AWS credentials रखते हैं

तीन caller-to-authorizer पंक्तियों में पहली: एक internal service, IAM auth से मैप.

दरवाज़ा कॉलर से मिलाएँ

कॉलर तय करता है

Internal service: पहले से AWS credentials रखते हैं
App user: Cognito टोकन साथ रखते हैं

तीन पंक्तियों में से दो: internal service → IAM auth, और app user → Cognito authorizer.

दरवाज़ा कॉलर से मिलाएँ

कॉलर तय करता है

Internal service: पहले से AWS credentials रखते हैं
App user: Cognito टोकन साथ रखते हैं
Partner app: अपना authorization logic लाता है

तीनों कॉलर अपने-अपने authorizer से मैप: internal service → IAM auth, app user → Cognito authorizer, partner app → Lambda authorizer.

API प्रकार पर ध्यान दें

REST API

तीनों authorizer, साथ में resource policies
API keys, per-client throttling, request validation, WAF

REST API के लिए तुलना कार्ड: IAM auth, Cognito user pool authorizer, Lambda authorizer, और resource policy टिक. बगल का HTTP API कार्ड अभी खाली है.

API प्रकार पर ध्यान दें

REST API

तीनों authorizer, साथ में resource policies
API keys, per-client throttling, request validation, WAF

HTTP API

JWT authorizer, कोई भी OIDC issuer
Resource policies नहीं; सस्ता और तेज़

दो कार्ड दिखाते हैं कि हर API प्रकार कौन-से authorizer सपोर्ट करता है: REST API में resource policies हैं, जबकि HTTP API Cognito authorizer की जगह JWT authorizer रखता है और resource policies नहीं हैं.

Authorizer याद रखती है

समय बचाने को cached

पहली कॉल: authorizer चलती है
बाद की कॉल: cache से उत्तर पढ़ें

पहली कॉल authorizer चलाकर allow को TTL सहित cache में लिखती है, और बाद की कॉल authorizer फिर चलाए बिना cache से allow पढ़ती है.

Authorizer याद रखती है

समय बचाने को cached

पहली कॉल: authorizer चलती है
बाद की कॉल: cache से उत्तर पढ़ें

Cache TTL

authorizerResultTtlInSeconds: डिफॉल्ट 300s, अधिकतम 3600s
शून्य करने पर caching बंद

Cached allow अपनी permission से ज़्यादा जी सकता है

दो-लेन टाइमलाइन. अनुमति लेन revoke बिंदु पर valid से revoked में बदलती है, जबकि नीचे cached allow लेन उस बिंदु के बाद भी allow दिखाती है; revocation के बाद की विंडो शेडेड है.

जिस क्षण आप revoke करते हैं

Permission: तुरंत रद्द
Cached allow: अब भी अनुमति दे रहा है

Cached allow अपनी permission से ज़्यादा जी सकता है

वही दो-लेन टाइमलाइन, revoke और TTL expiry के बीच की शेडेड विंडो चिह्नित: अभी भी allowed. Permission revoked है, पर cached allow एक्सेस देता रहता है.

बीच की विंडो

Permission हट गई, cache को पता नहीं
TTL खत्म होने तक एक्सेस जारी

Cached allow अपनी permission से ज़्यादा जी सकता है

वही टाइमलाइन, शेडेड विंडो पर एक तीर दिखाता है कि छोटा TTL expiry आगे खिसकाकर उस स्पैन को घटाता है जहाँ revoked permission फिर भी एक्सेस देती है.

उस विंडो को नियंत्रित करें

तेज़ revocation चाहिए तो TTL छोटा रखें
सबसे संवेदनशील routes पर TTL 0 रखें

एक कॉलर फ्रंट डोर छोड़ देता है

आपके अकाउंट के अंदर कोई third party

आपके बनाए role को assume करता है
आप role ARN साझा करते हैं

एक मॉनिटरिंग वेंडर दो ग्राहक बक्सों के बीच ऊपर और नीचे आपका role. आपका बॉक्स अपना role ARN वेंडर को देता है, जो आपका role assume करता है. दूसरा ग्राहक बॉक्स ग्रे है और अभी कहानी में नहीं.

एक कॉलर फ्रंट डोर छोड़ देता है

आपके अकाउंट के अंदर कोई third party

आपके बनाए role को assume करता है
आप role ARN साझा करते हैं

Role ARN कोई secret नहीं है

Confused deputy समस्या

दूसरा ग्राहक बॉक्स अब लाल में सक्रिय है और आपका role ARN अपने जैसा देकर साझा करता है. वेंडर से आपके role तक अब दो तीर हैं, प्रति ग्राहक एक कॉल, और दोनों में भेद नहीं.

एक कॉलर फ्रंट डोर छोड़ देता है

आपके अकाउंट के अंदर कोई third party

आपके बनाए role को assume करता है
आप role ARN साझा करते हैं

Role ARN कोई secret नहीं है

Confused deputy समस्या

उपाय: sts:ExternalId

वेंडर प्रत्येक ग्राहक के लिए एक जनरेट करता है
आपकी trust policy इस मिलान की मांग करती है

अब आपके role में शर्त है कि external ID 12345 हो. 12345 वाली कॉल role तक पहुँचती है, और 99999 वाली कॉल लाल क्रॉस से पहले ही रुक जाती है.

अभ्यास करते हैं!

डेवलपर्स के लिए AWS Security का उपयोग