संघबद्ध पहचान: SAML, OAuth और OpenID Connect

आधुनिक enterprises में employees को दर्जनों applications—cloud apps, SaaS tools, partner portals और internal systems—तक access चाहिए होता है, और इनमें से प्रत्येक को अलग-अलग organizations maintain कर सकती हैं। हर application के लिए अलग account बनाना और manage करना असुरक्षित (credential proliferation) तथा अक्षम है। Federated identity इस समस्या का समाधान Identity Provider (IdP) के माध्यम से करता है। IdP identity का trusted और authoritative source होता है, जो users को authenticate करके उस authenticated identity को organizational boundaries के पार Service Providers (SPs) के साथ साझा करता है। Users एक बार authenticate करके credentials दोबारा दर्ज किए बिना कई systems का access प्राप्त कर सकते हैं।

Single Sign-On (SSO) users को एक बार authenticate करके किसी session के दौरान दोबारा authentication किए बिना कई applications का access देता है। User Identity Provider (corporate Active Directory, Okta, Azure AD) में login करता है, session token या assertion प्राप्त करता है और जिन Service Providers पर जाता है, उनमें से प्रत्येक को यह token प्रस्तुत करता है। SSO से users को manage करने वाले passwords की संख्या घटती है (reuse कम होता है), centralized authentication policy लागू की जा सकती है और IdP स्तर पर account disable होने पर सभी integrated applications से access तुरंत revoke किया जा सकता है; इस प्रकार security बेहतर होती है।

SAML (Security Assertion Markup Language) 2.0 Identity Providers और Service Providers के बीच authentication तथा authorization data के आदान-प्रदान का XML-आधारित open standard है। SAML flow इस प्रकार है: (1) user किसी Service Provider (जैसे Salesforce) को access करता है, (2) SP उसे Identity Provider (जैसे Okta) पर redirect करता है, (3) user IdP पर authenticate करता है, (4) IdP user की identity और attributes वाली signed XML SAML Assertion जारी करता है, (5) assertion SP को वापस भेजी जाती है, (6) SP IdP की public key का उपयोग करके assertion की signature validate करता है और access देता है। Web applications में enterprise SSO के लिए SAML का व्यापक उपयोग होता है।

SAML federation में तीन parties भाग लेती हैं। Principal वह user (या system) है जो access चाहता है—authentication process उसी द्वारा शुरू किया जाता है। Identity Provider (IdP) identity का authoritative source है, जो principal को authenticate करता है और assertions जारी करता है—इसके उदाहरण Microsoft Azure AD, Okta, Ping Identity और ADFS हैं। Service Provider (SP) assertion का उपयोग करके access देता है—इसके उदाहरण Salesforce, Google Workspace, AWS और कोई भी SAML-enabled application हैं। SP और IdP पहले से trust स्थापित करते हैं; इसके लिए वे एक-दूसरे के endpoint URLs और signing certificates वाला metadata साझा करते हैं।

OAuth 2.0 एक authorization framework है (authentication protocol नहीं), जो किसी third-party application को user के behalf पर resources का access लेने देता है, बिना user के credentials उजागर किए। इसका सामान्य उपयोग है: 'इस photo editing app को आपकी Google Photos तक access देने की अनुमति दें।' OAuth 2.0 में चार roles होते हैं: Resource Owner (user), Client (third-party app), Authorization Server (tokens जारी करता है) और Resource Server (protected resource host करता है)। User client को authorization देता है, जिसके बाद client को access token मिलता है और वह इसे resource server के सामने प्रस्तुत करता है—उसे user के वास्तविक password की कभी आवश्यकता नहीं पड़ती।

Authorization Code Flow web applications के लिए सबसे secure OAuth 2.0 flow है। इसका क्रम है: (1) Client requested scopes के साथ user को Authorization Server पर redirect करता है; (2) User Authorization Server पर authenticate करके consent देता है; (3) Authorization Server एक short-lived authorization code के साथ वापस redirect करता है; (4) Client client credentials के साथ server-to-server call द्वारा code के बदले access token (और वैकल्पिक रूप से refresh token) प्राप्त करता है; (5) Client access token का उपयोग करके Resource Server को call करता है। Code exchange server-side होता है, जिससे access token के browser history या logs में उजागर होने का जोखिम नहीं रहता।

OpenID Connect (OIDC) OAuth 2.0 के ऊपर बनाया गया authentication layer है। OAuth केवल authorization देता है (access tokens यह प्रमाणित करते हैं कि client क्या कर सकता है); OIDC authentication जोड़ता है (एक ID token यह प्रमाणित करता है कि user कौन है)। OIDC OAuth flow में openid scope जोड़ता है और access token के साथ एक signed JWT (JSON Web Token) ID Token लौटाता है। ID token में claims (name, email, sub [subject identifier]) होते हैं, जो user की पहचान करते हैं। Consumer-facing SSO के लिए OIDC अब प्रमुख protocol है—'Sign in with Google/Apple/Microsoft' buttons सभी OIDC का उपयोग करते हैं।

JSON Web Tokens (JWT) parties के बीच claims दर्शाने का compact और URL-safe format हैं। JWT के तीन base64url-encoded parts होते हैं, जो dots से अलग किए जाते हैं: Header (algorithm और token type), Payload (claims: iss, sub, aud, exp, iat और custom claims) तथा Signature (token की integrity सत्यापित करने वाली cryptographic signature)। JWTs self-contained होते हैं—Resource Server Authorization Server को वापस call किए बिना इन्हें verify कर सकता है, जिससे performance बेहतर होती है और stateless architectures सक्षम होते हैं। महत्वपूर्ण security requirement है: JWT signature को हमेशा verify करें और exp (expiry) तथा aud (audience) claims की जाँच करें।

Security+ exam के लिए यह समझना महत्वपूर्ण है कि प्रत्येक standard कब लागू होता है। SAML 2.0: web applications के लिए enterprise SSO, browser-based flows और XML assertions। यह legacy है, लेकिन enterprise में व्यापक रूप से deployed है। OAuth 2.0: API authorization—third-party apps को resources तक सीमित access देना। यह users को सीधे authenticate नहीं करता। OIDC: consumer और आधुनिक enterprise authentication (SSO), जो OAuth 2.0 पर आधारित है। यह user की पहचान करने वाले JWT ID tokens लौटाता है। व्यवहार में enterprise environments अक्सर application SSO के लिए SAML और API/mobile authentication के लिए OIDC का उपयोग करते हैं। आधुनिक cloud-native environments अपने JSON/JWT format और बेहतर mobile support के कारण SAML की तुलना में OIDC को प्राथमिकता देते हैं।

Federated identity systems कुछ विशिष्ट attack vectors प्रस्तुत करते हैं। Assertion replay attacks: attacker किसी SAML assertion को intercept करके access पाने के लिए दोबारा भेजता है। इन्हें short assertion lifetimes और one-time-use assertion IDs से कम किया जा सकता है। XML signature wrapping (XSW): SAML में attackers कभी-कभी signed XML में बदलाव करके claims बदल सकते हैं, जबकि original content पर signature valid बनी रहती है। JWT algorithm confusion: यदि server RS256 (asymmetric) और HS256 (symmetric) दोनों algorithms स्वीकार करता है, तो attacker server की public key को HS256 के HMAC secret के रूप में उपयोग करके forged JWTs बना सकता है। हमेशा validate करें कि algorithm header अपेक्षित algorithm से मेल खाता है। Open redirectors: token theft रोकने के लिए OAuth redirect URIs का exact match होना आवश्यक है, ताकि redirection attacker-controlled sites पर न हो।

Enterprise identity federation में अक्सर systems के बीच user identity data को synchronize करना आवश्यक होता है। SCIM (System for Cross-domain Identity Management) Identity Provider और connected Service Providers के बीच user provisioning तथा deprovisioning को automate करने का REST API standard है। जब Azure AD (IdP) में कोई नया employee जोड़ा जाता है, तो SCIM Salesforce, Slack, GitHub और अन्य SCIM-compatible apps में उसका account अपने-आप बना देता है। Employee के organization छोड़ने पर SCIM सभी accounts को एक साथ deactivate कर देता है—इससे वह समयावधि समाप्त हो जाती है जिसमें orphaned accounts का दुरुपयोग किया जा सकता था। SCIM SSO protocols (SAML/OIDC) का पूरक है, क्योंकि यह lifecycle management संभालता है, जिसे SSO protocols address नहीं करते।

इस lesson में आपने सीखा: SAML 2.0 enterprise browser-based SSO के लिए XML assertions का उपयोग करता है; OAuth 2.0 API access delegation के लिए authorization framework है; OpenID Connect OAuth के ऊपर authentication (JWT ID tokens) जोड़ता है; और SCIM federated systems में identity lifecycle management को automate करता है। इससे Authentication और Authorization course पूरा होता है—अब हम Network Security Fundamentals का अध्ययन करेंगे।