ओपनआईडी कनेक्ट: कस्टम से मानक तक आंतरिक अनुप्रयोगों का प्राधिकरण

कुछ महीने पहले, मैं अपने सैकड़ों आंतरिक अनुप्रयोगों तक पहुंच प्रबंधित करने के लिए ओपनआईडी कनेक्ट सर्वर लागू कर रहा था। अपने स्वयं के विकास से, छोटे पैमाने पर सुविधाजनक, हम आम तौर पर स्वीकृत मानक पर चले गए हैं। केंद्रीय सेवा के माध्यम से पहुंच नीरस संचालन को बहुत सरल करती है, प्राधिकरणों को लागू करने की लागत को कम करती है, आपको कई तैयार समाधान खोजने की अनुमति देती है और नए विकसित करते समय अपने दिमाग को रैक नहीं करती है। इस लेख में, मैं इस बदलाव और उन बाधाओं के बारे में बात करूंगा जिन्हें हम भरने में कामयाब रहे।

बहुत समय पहले... यह सब कैसे शुरू हुआ

कुछ साल पहले, जब मैनुअल कंट्रोल के लिए बहुत सारे आंतरिक एप्लिकेशन थे, हमने कंपनी के भीतर एक्सेस को नियंत्रित करने के लिए एक एप्लिकेशन लिखा था। यह एक साधारण रेल एप्लिकेशन था जो डेटाबेस से कर्मचारियों के बारे में जानकारी के साथ जुड़ा था, जहां विभिन्न कार्यक्षमताओं तक पहुंच कॉन्फ़िगर की गई थी। उसी समय, हमने पहला SSO उठाया, जो क्लाइंट और प्राधिकरण सर्वर की ओर से टोकन के सत्यापन पर आधारित था, टोकन को कई मापदंडों के साथ एन्क्रिप्टेड रूप में प्रेषित किया गया था और प्राधिकरण सर्वर पर सत्यापित किया गया था। यह सबसे सुविधाजनक विकल्प नहीं था, क्योंकि प्रत्येक आंतरिक एप्लिकेशन को तर्क की काफी परत का वर्णन करना था, और कर्मचारी डेटाबेस पूरी तरह से प्राधिकरण सर्वर के साथ सिंक्रनाइज़ थे।

कुछ समय बाद, हमने केंद्रीकृत प्राधिकरण के कार्य को सरल बनाने का निर्णय लिया। एसएसओ को बैलेंसर में स्थानांतरित कर दिया गया था। OpenResty की मदद से, Lua में एक टेम्प्लेट जोड़ा गया था जो टोकन की जाँच करता था, जानता था कि किस एप्लिकेशन को अनुरोध किया जा रहा है, और जाँच कर सकता है कि वहाँ पहुँच है या नहीं। इस दृष्टिकोण ने आंतरिक अनुप्रयोगों तक पहुंच को नियंत्रित करने के कार्य को बहुत सरल बना दिया - प्रत्येक एप्लिकेशन के कोड में, अतिरिक्त तर्क का वर्णन करना अब आवश्यक नहीं था। नतीजतन, हमने ट्रैफ़िक को बाहरी रूप से बंद कर दिया, और एप्लिकेशन को स्वयं प्राधिकरण के बारे में कुछ भी नहीं पता था।

हालाँकि, एक समस्या अनसुलझी रही। उन एप्लिकेशन के बारे में क्या है जिन्हें कर्मचारियों के बारे में जानकारी चाहिए? प्राधिकरण सेवा के लिए एपीआई लिखना संभव था, लेकिन फिर आपको ऐसे प्रत्येक एप्लिकेशन के लिए अतिरिक्त तर्क जोड़ना होगा। इसके अलावा, हम अपने स्व-लिखित अनुप्रयोगों में से एक पर निर्भरता से छुटकारा पाना चाहते थे, जिसे बाद में हमारे आंतरिक प्राधिकरण सर्वर पर OpenSource में अनुवादित किया जाएगा। हम इसके बारे में फिर कभी बात करेंगे। दोनों समस्याओं का समाधान OAuth था।

सामान्य मानकों के लिए

OAuth एक समझने योग्य, आम तौर पर स्वीकृत प्राधिकरण मानक है, लेकिन चूंकि केवल इसकी कार्यक्षमता पर्याप्त नहीं है, इसलिए उन्होंने तुरंत OpenID Connect (OIDC) पर विचार करना शुरू कर दिया। OIDC स्वयं खुले प्रमाणीकरण मानक का तीसरा कार्यान्वयन है, जो OAuth 2.0 प्रोटोकॉल (एक खुला प्राधिकरण प्रोटोकॉल) पर ऐड-ऑन में प्रवाहित हुआ है। यह समाधान अंतिम उपयोगकर्ता के बारे में डेटा की कमी की समस्या को समाप्त करता है, और प्राधिकरण प्रदाता को बदलना भी संभव बनाता है।

हालांकि, हमने एक विशिष्ट प्रदाता का चयन नहीं किया और हमारे मौजूदा प्राधिकरण सर्वर के लिए ओआईडीसी के साथ एकीकरण जोड़ने का निर्णय लिया। इस निर्णय के पक्ष में यह तथ्य था कि ओआईडीसी अंतिम उपयोगकर्ता प्राधिकरण के मामले में बहुत लचीला है। इस प्रकार, आपके वर्तमान प्राधिकरण सर्वर पर ओआईडीसी समर्थन लागू करना संभव था।

हमारे अपने ओआईडीसी सर्वर को लागू करने का हमारा तरीका

1) डेटा को वांछित रूप में लाया

ओआईडीसी को एकीकृत करने के लिए, वर्तमान उपयोगकर्ता डेटा को मानक द्वारा समझने योग्य रूप में लाना आवश्यक है। ओआईडीसी में इसे दावा कहा जाता है। उपयोगकर्ता डेटाबेस (नाम, ईमेल, फोन, आदि) में दावे अनिवार्य रूप से अंतिम फ़ील्ड हैं। मौजूद डाक टिकटों की मानक सूची, और जो कुछ भी इस सूची में शामिल नहीं है उसे कस्टम माना जाता है। इसलिए, पहला बिंदु जिस पर आपको ध्यान देने की आवश्यकता है यदि आप एक मौजूदा ओआईडीसी प्रदाता का चयन करना चाहते हैं तो यह नए ब्रांडों के सुविधाजनक अनुकूलन की संभावना है।

हॉलमार्क के समूह को निम्नलिखित उपसमुच्चय में संयोजित किया जाता है - कार्यक्षेत्र। प्राधिकरण के दौरान, विशिष्ट ब्रांडों के लिए नहीं, बल्कि स्कोप के लिए एक्सेस का अनुरोध किया जाता है, भले ही स्कोप के कुछ ब्रांडों की आवश्यकता न हो।

2) आवश्यक अनुदान लागू किया

ओआईडीसी एकीकरण का अगला भाग प्राधिकरण प्रकारों, तथाकथित अनुदानों का चयन और कार्यान्वयन है। चयनित एप्लिकेशन और प्राधिकरण सर्वर के बीच सहभागिता का आगे का परिदृश्य चयनित अनुदान पर निर्भर करेगा। सही अनुदान चुनने के लिए एक अनुकरणीय योजना नीचे चित्र में दिखाई गई है।

हमारे पहले आवेदन के लिए, हमने सबसे आम अनुदान, प्राधिकरण कोड का उपयोग किया। दूसरों से इसका अंतर यह है कि यह तीन चरणों वाला है, अर्थात। अतिरिक्त परीक्षण किया जा रहा है। सबसे पहले, उपयोगकर्ता प्राधिकरण अनुमति के लिए अनुरोध करता है, एक टोकन - प्राधिकरण कोड प्राप्त करता है, फिर इस टोकन के साथ, जैसे कि यात्रा के लिए टिकट के साथ, एक्सेस टोकन का अनुरोध करता है। इस प्राधिकरण स्क्रिप्ट के सभी मुख्य इंटरैक्शन एप्लिकेशन और प्राधिकरण सर्वर के बीच रीडायरेक्ट पर आधारित हैं। आप इस अनुदान के बारे में अधिक पढ़ सकते हैं यहां.

OAuth इस अवधारणा का पालन करता है कि प्राधिकरण के बाद प्राप्त टोकन अस्थायी होना चाहिए और इसे बदलना चाहिए, अधिमानतः हर 10 मिनट में। प्राधिकरण कोड अनुदान पुनर्निर्देशन के माध्यम से एक तीन-चरणीय सत्यापन है, हर 10 मिनट में इस तरह के एक कदम को मोड़ना, स्पष्ट रूप से, आंखों के लिए सबसे सुखद कार्य नहीं है। इस समस्या को हल करने के लिए एक और अनुदान है - Refresh Token, जिसे हमने अपने देश में भी इस्तेमाल किया। यहाँ सब कुछ आसान है। एक अन्य अनुदान से सत्यापन के दौरान, मुख्य पहुँच टोकन के अलावा, एक अन्य जारी किया जाता है - ताज़ा टोकन, जिसका उपयोग केवल एक बार किया जा सकता है और इसका जीवनकाल आमतौर पर बहुत लंबा होता है। इस रीफ़्रेश टोकन के साथ, जब मुख्य एक्सेस टोकन का TTL (टाइम टू लाइव) समाप्त हो जाता है, तो एक नए एक्सेस टोकन के लिए अनुरोध दूसरे अनुदान के समापन बिंदु पर आ जाएगा। प्रयुक्त ताज़ा टोकन तुरंत शून्य पर रीसेट हो जाता है। यह जाँच दो-चरणीय है और इसे पृष्ठभूमि में, उपयोगकर्ता को किसी का पता नहीं चले, निष्पादित किया जा सकता है।

3) कस्टम डेटा आउटपुट स्वरूप सेट करें

चयनित अनुदानों के लागू होने के बाद, प्राधिकरण कार्य करता है, यह अंतिम उपयोगकर्ता के बारे में डेटा प्राप्त करने का उल्लेख करने योग्य है। इसके लिए OIDC का एक अलग समापन बिंदु है, जहां आप अपने वर्तमान एक्सेस टोकन के साथ उपयोगकर्ता डेटा का अनुरोध कर सकते हैं और यदि यह अद्यतित है। और यदि उपयोगकर्ता का डेटा इतनी बार नहीं बदलता है, और आपको कई बार वर्तमान का पालन करने की आवश्यकता होती है, तो आप JWT टोकन जैसे समाधान पर आ सकते हैं। ये टोकन भी मानक द्वारा समर्थित हैं। JWT टोकन में ही तीन भाग होते हैं: हेडर (टोकन के बारे में जानकारी), पेलोड (कोई भी आवश्यक डेटा) और हस्ताक्षर (हस्ताक्षर, टोकन सर्वर द्वारा हस्ताक्षरित होता है और आप बाद में इसके हस्ताक्षर के स्रोत की जांच कर सकते हैं)।

OIDC कार्यान्वयन में, JWT टोकन को id_token कहा जाता है। इसे नियमित एक्सेस टोकन के साथ अनुरोध किया जा सकता है और जो कुछ बचा है वह हस्ताक्षर को सत्यापित करना है। प्रारूप में सार्वजनिक कुंजी के समूह के साथ प्राधिकरण सर्वर के पास इसके लिए एक अलग समापन बिंदु है JWK. और इसके बारे में बोलते हुए, यह उल्लेखनीय है कि एक और समापन बिंदु है, जो मानक पर आधारित है RFC5785 OIDC सर्वर के वर्तमान कॉन्फ़िगरेशन को दर्शाता है। इसमें सभी समापन बिंदु पते (हस्ताक्षर करने के लिए उपयोग की जाने वाली सार्वजनिक कुंजी रिंग के पते सहित), समर्थित ब्रांड और कार्यक्षेत्र, प्रयुक्त एन्क्रिप्शन एल्गोरिदम, समर्थित अनुदान आदि शामिल हैं।

उदाहरण के लिए गूगल पर:

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
 "token_endpoint": "https://oauth2.googleapis.com/token",
 "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
 "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 "response_types_supported": [
  "code",
  "token",
  "id_token",
  "code token",
  "code id_token",
  "token id_token",
  "code token id_token",
  "none"
 ],
 "subject_types_supported": [
  "public"
 ],
 "id_token_signing_alg_values_supported": [
  "RS256"
 ],
 "scopes_supported": [
  "openid",
  "email",
  "profile"
 ],
 "token_endpoint_auth_methods_supported": [
  "client_secret_post",
  "client_secret_basic"
 ],
 "claims_supported": [
  "aud",
  "email",
  "email_verified",
  "exp",
  "family_name",
  "given_name",
  "iat",
  "iss",
  "locale",
  "name",
  "picture",
  "sub"
 ],
 "code_challenge_methods_supported": [
  "plain",
  "S256"
 ],
 "grant_types_supported": [
  "authorization_code",
  "refresh_token",
  "urn:ietf:params:oauth:grant-type:device_code",
  "urn:ietf:params:oauth:grant-type:jwt-bearer"
 ]
}

इस प्रकार, id_token का उपयोग करके, आप सभी आवश्यक हॉलमार्क को टोकन के पेलोड में स्थानांतरित कर सकते हैं और उपयोगकर्ता डेटा का अनुरोध करने के लिए हर बार प्राधिकरण सर्वर से संपर्क नहीं कर सकते हैं। इस दृष्टिकोण का नुकसान यह है कि सर्वर से उपयोगकर्ता डेटा में परिवर्तन तुरंत नहीं आता है, लेकिन एक नए एक्सेस टोकन के साथ।

कार्यान्वयन के परिणाम

इसलिए, अपने स्वयं के OIDC सर्वर को लागू करने और एप्लिकेशन साइड पर इसके कनेक्शन को कॉन्फ़िगर करने के बाद, हमने उपयोगकर्ताओं के बारे में जानकारी स्थानांतरित करने की समस्या को हल किया।
चूंकि ओआईडीसी एक खुला मानक है, हमारे पास मौजूदा प्रदाता या सर्वर कार्यान्वयन को चुनने का विकल्प है। हमने कीक्लोक को आजमाया, जो कॉन्फ़िगर करने के लिए बहुत सुविधाजनक साबित हुआ, एप्लिकेशन पक्ष पर कनेक्शन कॉन्फ़िगरेशन सेट अप करने और बदलने के बाद, यह जाने के लिए तैयार है। आवेदन पक्ष पर, जो कुछ भी शेष है वह कनेक्शन कॉन्फ़िगरेशन को बदलना है।

मौजूदा समाधानों के बारे में बात करना

हमारे संगठन के भीतर, पहले ओआईडीसी सर्वर के रूप में, हमने अपने कार्यान्वयन को इकट्ठा किया, जिसे आवश्यकतानुसार पूरक किया गया। अन्य तैयार समाधानों की विस्तृत समीक्षा के बाद, हम कह सकते हैं कि यह एक विवादास्पद बिंदु है। अपने स्वयं के सर्वर को लागू करने के निर्णय के पक्ष में, आवश्यक कार्यक्षमता के अभाव में प्रदाताओं की ओर से चिंताएं थीं, साथ ही एक पुरानी प्रणाली की उपस्थिति जिसमें कुछ सेवाओं के लिए अलग-अलग कस्टम प्राधिकरण थे और काफी कुछ कर्मचारियों के बारे में डेटा पहले ही संग्रहीत किया गया था। हालांकि, पहले से तैयार कार्यान्वयन में एकीकरण के लिए उपयुक्तताएं हैं। उदाहरण के लिए, Keycloak का अपना उपयोगकर्ता प्रबंधन सिस्टम है और इसमें सीधे डेटा संग्रहीत किया जाता है, और वहां आपके उपयोगकर्ताओं को ओवरटेक करना मुश्किल नहीं होगा। ऐसा करने के लिए, कीक्लोक के पास एक एपीआई है जो आपको सभी आवश्यक स्थानांतरण क्रियाओं को पूरी तरह से करने की अनुमति देगा।

मेरी राय में, प्रमाणित, दिलचस्प, कार्यान्वयन का एक और उदाहरण ओरी हाइड्रा है। यह दिलचस्प है क्योंकि इसमें विभिन्न घटक होते हैं। एकीकृत करने के लिए, आपको अपनी उपयोगकर्ता प्रबंधन सेवा को उनकी प्राधिकरण सेवा से लिंक करना होगा और आवश्यकतानुसार विस्तार करना होगा।

कीक्लोक और ओरी हाइड्रा केवल ऑफ-द-शेल्फ समाधान नहीं हैं। ओपनआईडी फाउंडेशन द्वारा प्रमाणित कार्यान्वयन का चयन करना सबसे अच्छा है। इन समाधानों में आमतौर पर एक OpenID प्रमाणन बैज होता है।

यदि आप अपना ओआईडीसी सर्वर नहीं रखना चाहते हैं तो मौजूदा सशुल्क प्रदाताओं के बारे में भी न भूलें। आज कई अच्छे विकल्प हैं।

आगे क्या है

निकट भविष्य में, हम आंतरिक सेवाओं के लिए यातायात को एक अलग तरीके से बंद करने जा रहे हैं। हम अपने वर्तमान SSO को बैलेंसर पर OpenResty का उपयोग करके OAuth पर आधारित प्रॉक्सी में स्थानांतरित करने की योजना बना रहे हैं। यहाँ पहले से ही कई तैयार समाधान हैं, उदाहरण के लिए:
github.com/bitly/oauth2_proxy
github.com/ory/oathkeeper
github.com/keycloak/keycloak-gatekeeper

अतिरिक्त सामग्री

jwt.io - JWT टोकन को मान्य करने के लिए अच्छी सेवा
openid.net/developers/प्रमाणित - प्रमाणित ओआईडीसी कार्यान्वयनों की सूची

स्रोत: www.habr.com