OpenID Connect: यह क्या है, प्रमाणीकरण और प्राधिकरण प्रोटोकॉल

OpenID Connect क्या है?

OpenID Connect (OIDC) एक खुला प्रमाणीकरण प्रोटोकॉल है जो OAuth 2.0 के ऊपर एक विस्तार के रूप में बनाया गया है। यह उस चीज़ को मानकीकृत करता है जो OAuth 2.0 में कमी थी: उपयोगकर्ता पहचान सत्यापन। यदि OAuth 2.0 प्रश्न “किस एप्लिकेशन के पास पहुंच है?” का उत्तर देता है, तो OIDC उत्तर देता है “यह उपयोगकर्ता वास्तव में कौन है?”

प्रोटोकॉल एक ID Token — एक JSON Web Token (JWT) जिसमें claims का सेट होता है: एक अद्वितीय विषय पहचानकर्ता, ईमेल, नाम, अवतार, जारी करने और समाप्ति के टाइमस्टैम्प — का उपयोग करता है। क्लाइंट एप्लिकेशन क्रिप्टोग्राफिक रूप से ID Token को सत्यापित कर सकता है — सर्वर RS256 या ES256 का उपयोग करके टोकन पर हस्ताक्षर करता है, और क्लाइंट JWKS एंडपॉइंट के माध्यम से प्राप्त सार्वजनिक कुंजी के विरुद्ध हस्ताक्षर की जांच करता है।

Auth0, 2025 के अनुसार, तृतीय-पक्ष प्रमाणीकरण का उपयोग करने वाले 78% से अधिक मोबाइल एप्लिकेशन Google Sign-In या Sign in with Apple के माध्यम से OIDC का उपयोग करते हैं। यह प्रोटोकॉल को सोशल लॉगिन और उद्यम प्रमाणीकरण के लिए वास्तविक मानक बनाता है।

OpenID Connect कैसे काम करता है

OpenID Connect क्लाइंट प्रकार के आधार पर कई प्रवाह (flows) परिभाषित करता है। मोबाइल एप्लिकेशन के लिए, मानक Proof Key for Code Exchange (PKCE) के साथ Authorization Code Flow है — यह डिवाइस पर client secret के बिना भी सुरक्षा प्रदान करता है।

Identity Provider और इसकी भूमिका

Identity Provider (IdP) एक सर्वर है जो उपयोगकर्ताओं को प्रमाणित करता है और टोकन जारी करता है। OIDC इकोसिस्टम में, IdP दो मुख्य एंडपॉइंट प्रदान करता है: उपयोगकर्ता लॉगिन के लिए Authorization Endpoint और कोड को टोकन में बदलने के लिए Token Endpoint। क्लाइंट Discovery URL — मानक पथ /.well-known/openid-configuration — के माध्यम से इन एंडपॉइंट के पतों का पता लगाता है, जो पूर्ण प्रदाता कॉन्फ़िगरेशन के साथ एक JSON दस्तावेज़ लौटाता है।

प्रत्येक IdP अपना JWKS (JSON Web Key Set) प्रकाशित करता है — ID Token हस्ताक्षर को सत्यापित करने के लिए सार्वजनिक कुंजियों का एक सेट। क्लाइंट इन कुंजियों को कैश करता है और सर्वर से संपर्क किए बिना प्राप्त प्रत्येक टोकन को सत्यापित करने के लिए उनका उपयोग करता है।

PKCE के साथ Authorization Code Flow

Authorization Code Flow एक तीन-चरणीय प्रक्रिया है। पहले, मोबाइल एप्लिकेशन एक code verifier (43–128 वर्णों की एक यादृच्छिक स्ट्रिंग) और इसका हैश — code challenge — उत्पन्न करता है। एप्लिकेशन एक ब्राउज़र या WebView खोलता है जिसमें client_id, redirect_uri, scope (openid profile email) और code challenge वाला URL होता है। उपयोगकर्ता IdP पृष्ठ पर क्रेडेंशियल दर्ज करता है और सहमति की पुष्टि करता है। IdP ब्राउज़र को authorization code के साथ वापस एप्लिकेशन पर रीडायरेक्ट करता है।

दूसरे चरण में, एप्लिकेशन authorization code, code verifier और client_id को सर्वर के Token Endpoint पर भेजता है। सर्वर code verifier को संग्रहीत code challenge के विरुद्ध सत्यापित करता है और ID Token, Access Token और वैकल्पिक रूप से Refresh Token लौटाता है। तीसरे चरण में, एप्लिकेशन ID Token को सत्यापित करता है: JWKS के विरुद्ध हस्ताक्षर को मान्य करता है, issuer (iss), audience (aud) और समाप्ति समय (exp) की जांच करता है। यदि सत्यापन पास हो जाता है, तो उपयोगकर्ता को प्रमाणित माना जाता है।

PKCE (Proof Key for Code Exchange) सार्वजनिक क्लाइंट्स में मानक Authorization Code Flow में निहित एक कमजोरी को समाप्त करता है। चूंकि मोबाइल एप्लिकेशन client secret को सुरक्षित रूप से संग्रहीत नहीं कर सकता, एक हमलावर जो authorization code को इंटरसेप्ट करता है, उसे टोकन के लिए बदल सकता है। Code verifier इस समस्या को हल करता है: भले ही कोड इंटरसेप्ट हो जाए, मूल code verifier के बिना आदान-प्रदान असंभव है। OAuth Security Best Practices (RFC 9700) को सभी सार्वजनिक क्लाइंट्स, जिसमें मोबाइल एप्लिकेशन शामिल हैं, के लिए PKCE की आवश्यकता है।

ID Token और Access Token

OpenID Connect दो मौलिक रूप से भिन्न टोकन लौटाता है: ID Token और Access Token। ID Token हमेशा एक JWT होता है जिसे क्लाइंट स्वयं पढ़ और सत्यापित कर सकता है। इसमें उपयोगकर्ता की जानकारी होती है और इसका उपयोग प्रमाणीकरण के लिए किया जाता है, API पहुंच के लिए नहीं।

ID Token की संरचना

ID Token में header, payload और signature होते हैं, जो Base64 में एन्कोडेड और बिंदुओं से अलग होते हैं। header में alg (हस्ताक्षर एल्गोरिदम) और kid (कुंजी पहचानकर्ता) होता है। payload में अनिवार्य claims शामिल हैं: iss (issuer), sub (subject — अद्वितीय उपयोगकर्ता ID), aud (audience — क्लाइंट पहचानकर्ता), exp (expiration), iat (issued at)। वैकल्पिक claims में name, email, picture, locale शामिल हैं।

Google से डिकोड किए गए ID Token payload का उदाहरण:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

Access Token एक अपारदर्शी टोकन (मनमाना स्ट्रिंग) या JWT है जिसे क्लाइंट API अनुरोधों में पास करता है। ID Token के विपरीत, access token क्लाइंट द्वारा पढ़े जाने के लिए नहीं है — इसका प्रारूप और सामग्री केवल संसाधन सर्वर और प्राधिकरण सर्वर को ज्ञात होती है। Access Token का एक scope — एक अनुमति प्रतिबंध — और एक छोटा जीवनकाल होता है, आमतौर पर 15–60 मिनट।

OpenID Connect और OAuth 2.0 के बीच अंतर

OAuth 2.0 एक प्राधिकरण ढांचा है जो परिभाषित करता है कि एप्लिकेशन उपयोगकर्ता के संसाधनों तक पहुंच कैसे प्राप्त करता है। OpenID Connect एक विस्तार है जो इस प्रक्रिया में प्रमाणीकरण जोड़ता है। मुख्य अंतर: OAuth 2.0 टोकन प्रारूप को परिभाषित नहीं करता है और एप्लिकेशन को यह जानने का तरीका नहीं देता कि अनुरोध वास्तव में किसने किया।

OpenID Connect को कब चुनें

OpenID Connect आवश्यक है जब एप्लिकेशन को उपयोगकर्ता की पहचान करने की आवश्यकता होती है, न कि केवल उनके डेटा तक पहुंच प्राप्त करने की। यदि आप “Google से साइन इन करें” या “Apple से साइन इन करें” का उपयोग करते हैं — यह OIDC है। यदि आपका एप्लिकेशन उपयोगकर्ता की ओर से किसी तृतीय-पक्ष API को कॉल करता है बिना उनकी पहचान जानने की आवश्यकता के — सादा OAuth 2.0 पर्याप्त है। Single Sign-On (SSO) वाले उद्यम सिस्टम के लिए, विकल्प स्पष्ट है: केवल OpenID Connect, क्योंकि यह मानकीकृत लॉगआउट और सत्र प्रबंधन प्रदान करता है।

मोबाइल एप्लिकेशन में OpenID Connect का कार्यान्वयन

OpenID Connect को मोबाइल एप्लिकेशन में एकीकृत करने के लिए सही लाइब्रेरी चुनना और प्रवाह को सही ढंग से कॉन्फ़िगर करना आवश्यक है। Android के लिए, credential manager (AndroidX Credentials) या AppAuth लाइब्रेरी का उपयोग करें। iOS के लिए, ASWebAuthenticationSession के साथ AuthenticationServices फ्रेमवर्क का उपयोग करें।

Kotlin कोड उदाहरण (Android)

नीचे AppAuth-Android लाइब्रेरी का उपयोग करके Authorization Code Flow शुरू करने का एक उदाहरण दिया गया है। एप्लिकेशन एक प्राधिकरण अनुरोध बनाता है, उपयोगकर्ता लॉगिन के लिए ब्राउज़र खोलता है, और टोकन के साथ कॉलबैक को संसाधित करता है।

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

Swift कोड उदाहरण (iOS)

Apple का ASWebAuthenticationSession iCloud Keychain के माध्यम से SSO समर्थन के साथ OIDC प्रवाह के लिए एक अंतर्निहित ब्राउज़र प्रदान करता है। सत्र प्राधिकरण URL के साथ शुरू होता है, और कॉलबैक एक completion handler के माध्यम से संभाला जाता है।

OpenID Connect के लिए लाइब्रेरी चुनते समय, अंतर्निहित PKCE समर्थन पर विचार करें: AppAuth-Android और AppAuth-iOS डिफ़ॉल्ट रूप से PKCE का समर्थन करते हैं। Firebase Authentication Google Sign-In, Sign in with Apple और Microsoft के लिए आंतरिक रूप से OIDC का उपयोग करता है — डेवलपर को मैन्युअल रूप से प्रवाह को लागू करने की आवश्यकता नहीं है। कस्टम IdP (जैसे, Keycloak या Okta) वाले उद्यम सिस्टम के लिए, AppAuth कॉन्फ़िगरेशन और त्रुटि प्रबंधन पर पूर्ण नियंत्रण के साथ मानक विकल्प बना हुआ है।

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()