OAuth, JWT और गेटवे: सुरक्षा नियंत्रण अलग रखें

उपकरण से पहले भूमिका चुनें

OAuth पहुँच टोकन अपारदर्शी हो सकता है या JWT उपयोग कर सकता है। JWT डिकोड करना प्रामाणिकता नहीं जाँचता; हस्ताक्षरित JWT सामग्री को अपने आप एन्क्रिप्ट नहीं करता। गेटवे सेवाओं के व्यावसायिक प्राधिकरण की जगह नहीं लेता।

प्रोटोकॉल और हर पहुँच सत्यापित करें

• क्लाइंट के अनुकूल प्रवाह चुनें। उपयोगकर्ता यात्राओं में रखरखाव वाली लाइब्रेरी और कड़े रीडायरेक्ट नियंत्रण के साथ वर्तमान authorization-code और PKCE अनुशंसाएँ अपनाएँ।
• स्वीकृत JWT में हस्ताक्षर, अनुमत एल्गोरिदम, जारीकर्ता, लक्षित प्राप्तकर्ता और प्रोफाइल की समय शर्तें जाँचें। दूसरे उपयोग के टोकन अस्वीकार करें।
• हर ऑब्जेक्ट, कार्रवाई और संगठन की पहुँच जाँचें। काल्पनिक डेटा से खातों के बीच पहुँच जाँचें; सामान्य भूमिका या दायरा हमेशा पर्याप्त नहीं होता।

समाप्ति, निरस्तीकरण और घटनाएँ भी तय करें

नवीनीकरण, कुंजी बदलाव, गोपनीय जानकारी खोने और निरस्तीकरण की रणनीति लिखें। स्थानीय सत्यापन दूर हुए निरस्तीकरण को अपने आप नहीं जानता। टोकन डेटा और लॉग सीमित करें; JWT या कोटा अकेले सुरक्षा या अनुपालन सुनिश्चित नहीं करते।

प्राथमिक स्रोत

• IETF RFC 9700 — OAuth 2.0 Security Best Current Practice [EN]
• IETF RFC 8725 — JWT Best Current Practices [EN]
• OpenID Foundation — OpenID Connect Core 1.0 [EN]
• OWASP — Authorization Cheat Sheet [EN]

{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

{
    "issuance_succeeded": true,
    "proxy_count": 2,
    "proxies_serving_expected_certificate": 1,
    "other_proxy_certificate_expired": true,
    "tls_verification_enabled": true,
    "expected": "change_incomplete_fix_and_verify_client_paths"
}