💪 🕉️ 👎🏾 ओपनआईडी कनेक्ट: जेनेरिक से मानक तक आंतरिक अनुप्रयोगों का प्राधिकरण 🚴 👅 ☺️

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

परिचय

एक बार ... यह सब कैसे शुरू हुआ

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

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

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

आम तौर पर स्वीकृत मानकों को

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

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

हमारे अपने OIDC सर्वर को लागू करने का हमारा तरीका

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

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

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

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

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

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

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

3) अनुकूलित उपयोगकर्ता डेटा आउटपुट स्वरूप

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

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

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

{
 "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 सर्वर के रूप में, हमने अपने कार्यान्वयन को एक साथ रखा, जिसे आवश्यकतानुसार पूरक किया गया था। अन्य तैयार किए गए समाधानों की विस्तृत समीक्षा के बाद, हम कह सकते हैं कि यह एक मूट बिंदु है। प्रदाताओं की ओर से आवश्यक कार्यक्षमता की कमी के बारे में उनके सर्वर के कार्यान्वयन के समाधान के साथ-साथ एक पुरानी प्रणाली की उपस्थिति जिसमें कुछ सेवाओं के लिए विभिन्न कस्टम प्राधिकरण थे और कर्मचारियों के बारे में काफी डेटा संग्रहीत किया गया था। हालांकि, तैयार-किए गए कार्यान्वयन में, एकीकरण की सुविधा है। उदाहरण के लिए, कीक्लॉक की अपनी उपयोगकर्ता प्रबंधन प्रणाली है और इसमें डेटा सीधे संग्रहीत किया जाता है, और वहां अपने उपयोगकर्ताओं से आगे निकलना मुश्किल नहीं होगा। इसके लिए, कीक्लोक में एक एपीआई है जो आपको हस्तांतरण के लिए सभी आवश्यक चरणों को पूरी तरह से लागू करने की अनुमति देगा।

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

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

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

आगे क्या होगा

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

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

jwt.io -
openid.net/developers/certified JWT टोकन की जाँच के लिए एक अच्छी सेवा - प्रमाणित OIDC कार्यान्वयन की एक सूची

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