OAuth 2.0 integration security: SaaS implementation मार्गदर्शिका
Authorization code और PKCE, exact redirect matching, least-privilege scopes, जाँचे tokens और tested revocation रास्ते से SaaS OAuth integrations सुरक्षित करें।
इस मार्गदर्शिका में
OAuth क्या करता है और teams कहाँ भ्रमित होती हैं?
OAuth 2.0 client को user की ओर से resource access करने की सीमित अनुमति पाने देता है। OAuth authorization framework है; OpenID Connect (OIDC), sign-in के लिए identity layer जोड़ता है। यदि product को केवल delegated API access चाहिए तो access token को user की पहचान का प्रमाण न मानें। Login चाहिए तो सही OIDC flow अपनाएँ और identity token तथा उसके claims validate करें।
Client के अनुसार flow चुनें और authorization code के साथ PKCE लगाएँ
Browser, mobile और अन्य public clients के लिए Proof Key for Code Exchange (PKCE) वाला authorization-code flow अपनाएँ और `S256` challenge method इस्तेमाल करें। RFC 9700 confidential clients के लिए भी PKCE की सिफारिश करता है क्योंकि यह code injection और misuse रोकने में मदद करता है। जाँची OAuth/OIDC library लें और पुष्टि करें कि authorization server token exchange पर verifier लागू करता है।
Redirect URI exact रखें और open redirect रोकें
हर अनुमति प्राप्त redirect URI register करें और standard में native apps के localhost port exception को छोड़कर exact matching करें। Query parameter से मनमाना redirect स्वीकार न करें और broad wildcards न लगाएँ। Open redirect authorization code या token attacker के नियंत्रण वाले पते पर भेज सकता है।
Integration को केवल जरूरी scopes दें
हर integration को किन API actions की जरूरत है, सूची बनाएँ और सबसे कम available scopes माँगें। Consent से पहले access सरल भाषा में समझाएँ, जहाँ provider support करे वहाँ read और write privileges अलग रखें और केवल narrow endpoint उपयोग करने वाले feature के लिए broad scopes न माँगें। Product बदले तो scopes फिर देखें।
| Client / provider | Redirect URI | Scopes और purpose | Token storage / expiry | Revocation test / owner |
|---|---|---|---|---|
SaaS OAuth client authorization response और tokens कैसे बचाए?
हर authorization कोशिश को browser session से बाँधें
हर कोशिश के लिए अलग PKCE values बनाएँ और उन्हें client तथा user agent से सुरक्षित रूप से जोड़ें। PKCE सुरक्षा पर निर्भर न होने पर CSRF defense के लिए उसी कोशिश से जुड़ा एक बार उपयोग होने वाला `state` रखें; OIDC में नया `nonce` भेजें और ID token में validate करें। Fixed state, nonce या verifier दोबारा इस्तेमाल न करें।
Token का सही issuer, audience और purpose जाँचें
OIDC ID token के लिए trusted keys से signature validate करें और account जोड़ने से पहले issuer, audience, expiry, nonce तथा जरूरी claims जाँचें। Access token के लिए provider का documented validation या introspection तरीका लें और intended resource तथा permissions verify करें। JWT को decode करना उसका validation नहीं है।
Access और refresh tokens को logs तथा असुरक्षित storage से बचाएँ
Bearer token को credential मानें: इसे रखने वाला कोई भी व्यक्ति इसका इस्तेमाल कर सकता है। जहाँ संभव हो tokens को protected server-side secret store में रखें, संवेदनशील records encrypt करें और केवल जरूरतमंद integration worker को access दें। Authorization headers, callback query values और token responses को logs तथा analytics से redact करें। उजागर client credentials rotate करें।
SaaS teams consent, renewal और revocation कैसे संभालें?
जहाँ उपलब्ध हो refresh-token सुरक्षा और कम अवधि वाले access अपनाएँ
Provider के refresh-token rotation या sender-constraining controls का पालन करें, provider support करे तो reuse पहचानें और नया token सुरक्षित रखें। Revoked consent, invalid grant, expiry और provider outage का स्पष्ट response बनाएँ; बार-बार refresh failure को endless retry loop न बनने दें।
स्पष्ट disconnect और revocation रास्ता दें
Account owner को integration disconnect करने दें; scheduled jobs रोकें, stored tokens हटाएँ और जहाँ provider support करे authorization server पर grant revoke करें। बताएँ कि आपके product से integration हटाने से दोनों systems में पहले से copy हुआ data जरूरी नहीं मिटे। Disconnect path test करें और केवल जरूरी audit record रखें।
Deprecated या असुरक्षित grant patterns से बचें
नई integration को implicit grant या Resource Owner Password Credentials grant पर न बनाएँ। RFC 9700 कम सुरक्षित तरीकों को deprecate करता है; समर्थित authorization-code design और provider के current documentation का उपयोग करें। User के बिना service-to-service access के लिए उचित authentication वाला client-credentials design और सीमित service identity चुनें।
OAuth 2.0 integration security के सवाल
क्या OAuth access token और OIDC identity token एक ही हैं?
नहीं। Access token resource access की अनुमति देता है और opaque भी हो सकता है। OIDC ID token client के लिए authentication claims रखता है। हर token को उसके सही purpose के लिए validate करें; केवल API access token से किसी व्यक्ति को signed in न मानें।
क्या PKCE सिर्फ mobile apps के लिए है?
नहीं। PKCE पहले public clients के लिए तय हुआ था; RFC 9700 confidential clients के लिए भी इसकी सिफारिश करता है। `S256` इस्तेमाल करें, verifier को authorization प्रयास से जोड़ें और सुनिश्चित करें कि server token endpoint पर इसे जाँचता है।
क्या हर customer और environment के लिए एक redirect URI उपयोग कर सकते हैं?
Shared callback चल सकती है यदि वह exact registered हो और client response को सही tenant तथा authorization प्रयास से सुरक्षित जोड़े। मनमाने या broad wildcard redirect destinations न रखें। जहाँ configuration और credential का जोखिम घटे वहाँ production और test clients अलग रखें।
क्या SaaS app में connection हटाने से provider access revoke हो जाता है?
हमेशा नहीं। Product को stored credentials हटाने या बंद करने चाहिए और उपलब्ध होने पर provider का revocation endpoint या documented disconnect flow चलाना चाहिए। पहले से synced data, queued jobs और provider-side grants को भी देखें जिन्हें user को अलग हटाना पड़ सकता है।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .