🌅 📐 😇 आधुनिक पहचान मानक: OAuth 2.0, OpenID कनेक्ट, WebAuthn 🗂️ 👩🏼‍✈️ 👨‍👩‍👦‍👦

जाने या न देने के लिए? यह सवाल है…

अब कई साइटों पर हम सामाजिक नेटवर्क का उपयोग करके पंजीकरण या लॉग इन करने का अवसर देखते हैं, और कुछ साइटें बाहरी सुरक्षा कुंजी या उंगलियों के निशान का उपयोग करती हैं। यह क्या है? अच्छी तरह से डिजाइन सुरक्षा मानकों या मालिकाना कार्यान्वयन? क्या हम इन तकनीकों पर भरोसा कर सकते हैं और उनका उपयोग वेबसाइट विकास और रोजमर्रा की जिंदगी में कर सकते हैं? चलो ठीक है। इसलिए, अब OAuth 2.0, OpenID Connect, WebAuthn, SAML 2.0, क्रेडेंशियल मैनेजमेंट API आदि के उपयोगकर्ताओं की पहचान करने के लिए कई मानक और प्रौद्योगिकियाँ हैं। इस लेख में मैं तीन सबसे होनहार प्रोटोकॉल OAuth 2.0, OpenID Connect और WebAuthn के बारे में बात करूंगा। और यह समझने के लिए कि उन्हें कैसे व्यवहार में लाना है, हम तीन प्रयोगशाला काम करेंगे। हम उपयोगकर्ताओं की पहचान के लिए प्लेटफ़ॉर्म के रूप में GitHub और Google का उपयोग करेंगे।जिस पर ज्यादातर खाते हैं।

OAuth 2.0

चलो सबसे प्रसिद्ध OAuth 2.0 प्रोटोकॉल के साथ शुरू करते हैं। इसे 2012 में RFC 6749: OAuth 2.0 प्राधिकरण फ्रेमवर्क के रूप में प्रकाशित किया गया था ।

OAuth 2.0 का उपयोग करते हुए, एक उपयोगकर्ता एक विशिष्ट साइट को सामाजिक नेटवर्क से अपना निजी डेटा प्राप्त करने की अनुमति देता है, लेकिन साइट पर अपने लॉगिन / पासवर्ड को स्थानांतरित किए बिना। उदाहरण के लिए, जब आप फेसबुक के माध्यम से किसी साइट पर पंजीकरण करते हैं, तो आप इस साइट को फेसबुक से अपना नाम, ई-मेल पता और अन्य निजी डेटा प्राप्त करने की अनुमति देते हैं।

चलो तकनीकी कार्यान्वयन से निपटते हैं। सादगी के लिए, मैं सोशल नेटवर्क पर उपयोगकर्ता क्रेडेंशियल्स को संग्रहीत करने वाली किसी भी साइट को कॉल करूंगा। और MySite किसी भी साइट या एप्लिकेशन का नाम देगा जो सोशल नेटवर्क से उपयोगकर्ता डेटा प्राप्त करना चाहता है।

मानक निम्नलिखित भूमिकाओं को परिभाषित करता है:

Resource Owner — , MySite .
Client ( MySite) — , Authorization Server Resource Server .
Authorization Server — / , .
Resource Server — , API. Authorization Server Resource Server .

Authorization flow

MySite :
MySite Name ( ), Homepage ( MySite) Callback (, )
सोशल नेटवर्क क्लाइंट आईडी (जिसे कभी-कभी ऐपिड कहा जाता है) और क्लाइंट सीक्रेट देता है।
डेवलपर आईडी क्लाइंट आईडी और क्लाइंट सीक्रेट में पंजीकृत होनी चाहिए।

अब प्रक्रिया ही। विशिष्ट कार्यान्वयन के विवरण भिन्न हो सकते हैं, लेकिन सामान्य तर्क हमेशा निम्नानुसार होंगे:

क्लाइंट (MySite) पर रिसोर्स ओनर लॉग्स, "सोशल नेटवर्क का उपयोग करने में लॉग" विकल्प का चयन करता है, साइट ऑथराइजेशन सर्वर पर उपयोगकर्ता को सोशल नेटवर्क पर रीडायरेक्ट करती है।
प्राधिकरण सर्वर जाँचता है कि क्या उपयोगकर्ता के पास एक सक्रिय सत्र है और यदि नहीं, तो लॉगिन फ़ॉर्म प्रदर्शित करता है।
रिसोर्स ओनर अपने यूज़रनेम / पासवर्ड को दर्ज करता है और पुष्टि करता है कि कुछ निजी डेटा का उपयोग MySite द्वारा किया जा सकता है, जैसे कि उपयोगकर्ता नाम या ई-मेल पता।
प्राधिकरण सर्वर उपयोगकर्ता की पुष्टि करता है और प्रमाणीकरण परिणाम और "प्राधिकरण कोड" के साथ कॉलबैक पते पर रीडायरेक्ट करता है।
Client “Authorization Code”, Client ID Client Secret.
Authorization Server “access token” JWT (JSON Web Token), . JWT “refresh token”, c .
Client API, “access token”.
Resource Server “access token” (, Authorization Server) .

OAuth 2.0 (GitHub)

सामाजिक नेटवर्क का उपयोग करके OAuth 2.0 प्राधिकरण को कैसे लागू किया जाए, इस पर कई निर्देश हैं। मुझे व्यक्तिगत रूप से निम्नलिखित लेख पसंद आया: NodeJS के साथ GitHub OAuth 2.0 का उपयोग करके प्रमाणीकरण यह चरणों का विवरण देता है और एक परीक्षण कार्यक्रम प्रदान करता है। लेकिन एल्गोरिथ्म को वास्तव में समझने के लिए, अपने हाथों से सभी चरणों से गुजरना बेहतर होता है (ब्राउज़र से HTTP अनुरोध या वक्र करने के लिए कॉल)। जाओ।

आरंभ करने के लिए, GitHub पर अपना आवेदन पंजीकृत करें: github.com/settings/applications/new

पैरामीटर सेट करें:

होम पेज: मायसाइट / होम
कॉलबैक: मायसाइट / कॉलबैक

प्राधिकरण को अपनी साइट के भीतर काम करने के लिए, पते वास्तविक होने चाहिए, लेकिन प्रयोगशाला के काम के लिए यह आवश्यक नहीं है।

GitHub से प्राप्त करें:

ग्राहक आईडी: ab8ec08a620c2
क्लाइंट सीक्रेट: e6fdd52b0a99e8fbe76b05c1b7bb93c1e

बेशक, सभी प्रयोगशाला कार्यों में सभी मूल्य नकली हैं।

यह कैसे GitHub वेबसाइट पर क्लाइंट आईडी और सीक्रेट प्राप्त कर रहा है जैसा दिखता है:

अब हम प्राधिकरण शुरू करते हैं। हम मानते हैं कि चरण 1 पहले ही पूरा हो चुका है: उपयोगकर्ता ने MySite पर लॉग इन किया और "GitHub का उपयोग करके लॉग इन" का चयन किया। कॉल प्रवाह का चरण 2 REST प्रारूप में एक कॉल है:

https://github.com/login/oauth/authorize?client_id=ab8ec08a620c2

पता github पर लॉगिन बिंदु है
client_id पंजीकरण के दौरान जारी क्लाइंट आईडी है

इस कॉल के परिणामस्वरूप, GitHub प्राधिकरण के लिए एक विंडो दिखाता है:

चरण 3: GitHub

चरण 4 तक पहुंचने के लिए लॉगिन / पासवर्ड दर्ज करें : GitHub होमपेज पर अनुरोध को पुनर्निर्देशित करता है, इस अनुरोध में हम कोड देखते हैं:

http://MySite/home?code=a29b348f63d21

इस पते पर कोई कार्यशील साइट नहीं है, लेकिन हमारे लिए मुख्य बात यह है कि अगले चरण 5 को बनाने के लिए भेजे गए कोड को जानें:

https://github.com/login/oauth/access_token?client_id=ab8ec08a620c2&
client_secret=e6fdd52b0a99e8fbe76b05c1b7bb93c1e&
code=a29b348f63d21

पता GitHub पर एक्सेस टोकन प्राप्त करने वाला बिंदु है
client_id पंजीकरण के दौरान जारी क्लाइंट आईडी है
client_secret एक क्लाइंट सीक्रेट है जिसे पंजीकरण के दौरान जारी किया गया है
कोड केवल भेजा गया कोड है

चरण 6: प्रतिक्रिया में टोकन प्राप्त हुआ:

access_token=31b71cbd372acdbb20ec1644b824f3dd0&scope=&token_type=bearer

चरण 7: access_token को रिक्वेस्ट हेडर में डालें और GitHub API को कॉल करें:

curl -H "Authorization: token 31b71cbd372acdbb20ec1644b824f3dd0" https://api.github.com/user

चरण 8: प्रतिक्रिया में, हमें JSON से मेरे बारे में उपयोगी जानकारी मिलती है जिसका उपयोग आप MySite पर एक प्रोफ़ाइल बनाने के लिए कर सकते हैं:

{
  "login": "AlexeySushkov",
  "html_url": "https://github.com/AlexeySushkov",
  "repos_url": "https://api.github.com/users/AlexeySushkov/repos",
  "name": "Alexey Sushkov",
  "blog": "http://sushkov.ru",
  "location": "St.Petersburg, Russia",
  "email": "alexey.p.sushkov@gmail.com",
 ..
}

वास्तव में, हमने केवल एक OAuth 2.0 परिदृश्य की जांच की। कई परिदृश्य हैं, जिनमें से प्रत्येक का उपयोग अनुप्रयोग, सुरक्षा विचारों, परिनियोजन विधि, आदि के आधार पर किया जाता है। सभी परिदृश्यों का वर्णन पाया जा सकता है, उदाहरण के लिए, यहाँ: OAuth 2.0 एक संक्षेप में ।

ओपनिड कनेक्ट

OAuth 2.0 के साथ थोड़ा समझा। अब आइए जानें कि हमें OpenID कनेक्ट की आवश्यकता क्यों है, जो OAuth 2.0 के लिए एक ऐड-ऑन है:

C OAuth 2.0 .. access token, . access token MySite. OpenID Connect — (identity). .
OpenID Connect “service discovery”. SSO (Single Sign-On), .

आइए तकनीकी पक्ष से मानक को देखें।

ओपेनआईडी कनेक्ट (ओआईडीसी) ओपेनआईडी फाउंडेशन कंसोर्टियम द्वारा विकसित एक ओपन ओपनआईडी मानक है । OIDC निम्नलिखित प्रमुख विशेषताओं के साथ OAuth 2.0 का विस्तार करता है:

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

OpenID कनेक्ट में इंटरएक्शन आरेख OAuth के साथ समान दिखता है। अनुरोधों की सामग्री में एकमात्र अंतर:

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

OpenID कनेक्ट: लैब (Google)

अब देखते हैं कि Google इस विषय पर हमें क्या प्रसन्न करेगा। Google से OpenID कनेक्ट को कॉन्फ़िगर करने और उपयोग करने के लिए विस्तृत निर्देश हैं और Google API का उपयोग करने के लिए एक सैंडबॉक्स: Google OAuth 2.0 प्लेग्राउंड ।

यहां, OAuth 2.0 के मामले में, हम चरणों के माध्यम से जाएंगे और आने वाले डेटा को देखेंगे। इसी तरह, हम मानते हैं कि आवेदन पंजीकृत है, क्लाइंट आईडी और क्लाइंट सीक्रेट प्राप्त किया जाता है, चरण 1 पारित किया जाता है। कॉल प्रवाह का चरण 2 REST प्रारूप में एक कॉल है:

https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
client_id=140797064495-b8b79j42m97nkkrlndfstikv8.apps.googleusercontent.com&
scope=openid%20email&
redirect_uri=http%3A//c18529.shared.hc.ru/wp-login.php&
state=765439764

Google थोड़ा अधिक जटिल है, क्योंकि वे सुरक्षा पर अधिक ध्यान देते हैं:

पता Google पर लॉगिन बिंदु है
response_type = code - प्रतिक्रिया में कोड प्राप्त करने की अपेक्षा करता है
client_id - क्लाइंट आईडी पंजीकरण के दौरान जारी किया गया
स्कोप = ओपिड ईमेल - हम किस डेटा का उपयोग करना चाहते हैं
redirect_uri - redirect_uri आवेदन पंजीकरण के दौरान निर्दिष्ट किया गया है
राज्य - क्लाइंट द्वारा उत्पन्न संख्या, जो घुसपैठिया हस्तक्षेप से बचाने के लिए क्लाइंट और एएस के बीच प्रेषित की जाती है।

चरण 3: कोई पासवर्ड प्रविष्टि फ़ॉर्म नहीं है, जैसा कि मैं पहले से ही Google में लॉग इन था।

चरण 4: Google मुखपृष्ठ पर अनुरोध को पुनर्निर्देशित करता है, इस अनुरोध में हम कोड देखते हैं:

http://MySite?state=123&code=4/xAFkcMzhyJhUErRJYwIyntSYN-WeJjfZHLiwWL4IaT-WkHzMU18xABlPmev-M_87wVbqTkQ1y93w6GB5&scope=email+openid+https://www.googleapis.com/auth/userinfo.email&authuser=0&prompt=none

जैसे कि GitHub के मामले में, इस पते पर कोई भी कार्यशील वेबसाइट नहीं है, लेकिन यह आवश्यक नहीं है, हमारे लिए मुख्य बात यह है कि अगले चरण 5 को बनाने के लिए कोड जानना चाहिए। यह भी थोड़ा अधिक जटिल है, क्योंकि Google को POST अनुरोध की आवश्यकता है, GET की नहीं:

curl -d "code=4/xAFkcMzhyJhUErRJYwIyntSYN-WeJjfZHLiwWL4IaT-WkHzMU18xABlPmev-M_87wVbqTkQ1y93w6GB5&client_id=140797064495-b8b79j42m97nkkrlndfstikv8.apps.googleusercontent.com&
client_secret=HMVctrTicW6RC1Q8T&
redirect_uri=http%3A//c18529.shared.hc.ru/wp-login.php&
grant_type=authorization_code" 
-H "Content-Type: application/x-www-form-urlencoded" -X POST https://oauth2.googleapis.com/token

पता Google पर टोकन प्राप्त करने का बिंदु है
कोड केवल भेजा गया कोड है
client_id पंजीकरण के दौरान जारी क्लाइंट आईडी है
client_secret एक क्लाइंट सीक्रेट है जिसे पंजीकरण के दौरान जारी किया गया है
अनुदान_प्रकार = प्राधिकरण_कोड - मानक से एकमात्र मान्य मूल्य

चरण 6: प्रतिक्रिया में access_token और id_token प्राप्त किया:

{
  "access_token": "ya29.Il_AB0KeKnjBJx0dhjm2nCLt1B-Mq0aQBW5T302JnlZfsxW1AXqLFfDJZRMi2R2WKG4OX4msKLjx4E4CSl4G_4ajAy3aqrf4pM0ic0jJr092pA67H9aktJktCbx",
  "expires_in": 3327,
  "scope": "openid https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjE3ZDU1ZmY0ZTEwOTkxZDZiMGVmZDM5MmI5MWEzM2U1
………………………………_…………………………………………………….._4mUTiMNSAHljap1hLD2hAzgOZWuQ"
}

अब इस दौलत का क्या करें?

चरण 7: access_token के साथ सब कुछ स्पष्ट है: हम इसे एक एपीआई कॉल में शामिल करते हैं, उदाहरण के लिए GMail:

curl -H "Authorization: Bearer ya29.a0Adw1xeWvFoxHKNICHnV6vFFj5TZdPQVlYD98h8wjW95ZEbHVui_pk7HGRoq3Q7MlVLV23xkVM0yyjSP8ClSlvfUy3b_IqvKQW5Lvwj38QzJhee-aH1grerB4pRpMzn_FGueigG_RGI56pKPgFBTr49cpynQy" https://www.googleapis.com/gmail/v1/users/alexey.p.sushkov@gmail.com/profile

चरण 8: प्रतिक्रिया में, हमें JSON उपयोगी जानकारी मिलती है:

{
 "emailAddress": "alexey.p.sushkov@gmail.com",
 "messagesTotal": 372543,
...
}

अब आइए इस कथन की जाँच करें कि id_token में उपयोगकर्ता को प्रमाणित करने और सत्र को बनाए रखने के लिए जानकारी है। ऐसा करने के लिए, आपको सामग्री को डिक्रिप्ट करने की आवश्यकता है। इसका सबसे आसान तरीका यह है कि Google API को
oauth2.googleapis.com/tokeninfo पर संपर्क करें और प्राप्त id_token को एक पैरामीटर के रूप में निर्दिष्ट करें:

https://oauth2.googleapis.com/tokeninfo?id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjE3ZDU1ZmY0ZTEwOTkxZDZiMGVmZDM5MmI5MWEzM2U1NGMwZTIxOGIiLCJ0eXAiOi
………………………_……………………………...
SVQ5GQni3irfOzOXYEiqijp6TjGa_a-3jKcEsU5TbasZmAIejsdVcNy2_4mUTiMNSAHljap1hLD2hAzgOZWuQ

समझे JSON:

{
  "iss": "https://accounts.google.com",
  "email": "alexey.p.sushkov@gmail.com",
  "email_verified": "true",
  "iat": "1583257010",
  "exp": "1583260610",
  "typ": "JWT"
...
}

हम देखते हैं कि id_token में उपयोगकर्ता के लॉगिन, प्राप्ति के समय और टोकन के जीवनकाल के बारे में जानकारी शामिल है। हम यह निष्कर्ष निकाल सकते हैं कि Google से OpenID कनेक्ट काम कर रहा है, और इसका उपयोग प्रासंगिक परिदृश्यों के लिए किया जा सकता है।

Webauthn

वेब ऑथेंटिकेशन API (जिसे WebAuthn के नाम से भी जाना जाता है):

मानक उपयोगकर्ताओं को वेबसाइटों पर और बाहरी सुरक्षा कुंजी (उदाहरण के लिए, USB कुंजी) या फिंगरप्रिंट और बाद में, बायोमेट्रिक डेटा: फेस, रेटिना का उपयोग करके वेबसाइटों पर खुद को पहचानने की अनुमति देता है।
— / «Public key cryptography». Public key cryptography — , . Private key ( ) , public key ( ) .
W3C (World Wide Web Consortium) FIDO, Google, Mozilla, Microsoft, Yubico. W3C HTTP, HTML, XML . WebAuthn. WebAuthn : Chrome, Firefox, Edge, Safari.

OAuth 2.0 की तुलना में, WebAuthn में निम्न भूमिकाएँ जोड़ी जाती हैं:

प्रमाणक : एक बाहरी सुरक्षा कुंजी (भौतिक मीडिया या फ़िंगरप्रिंट स्कैनर) जो विभिन्न तकनीकों का उपयोग करके उपयोगकर्ता को प्रमाणित करती है, जैसे ब्लूटूथ / एनएफसी / यूएसबी। इसके लिए कार्य करता है:

सार्वजनिक कुंजी क्रेडेंशियल (सार्वजनिक / निजी कुंजी जोड़े) की पीढ़ी।
लेखक अपनी मेमोरी में निजी कुंजी को सुरक्षित रूप से संग्रहीत करता है
बाहरी प्रणालियों के लिए सार्वजनिक कुंजी देता है
एक निजी कुंजी के साथ डेटा पर हस्ताक्षर करता है और परिणाम को बाहरी सिस्टम में स्थानांतरित करता है

प्रमाणीकरणकर्ता CTAP प्रोटोकॉल (क्लाइंट टू ऑथेंटिकेटर प्रोटोकॉल) का उपयोग ब्राउज़र के साथ बातचीत करने के लिए करता है।

Relying Party : OAuth 2.0 में "प्राधिकरण सर्वर" के रूप में एक ही कार्य करता है, अर्थात्, उपयोगकर्ता की पहचान की पुष्टि करता है। केवल OAuth 2.0 में यह उपयोगकर्ता नाम / पासवर्ड था, और वेनहटन में यह सार्वजनिक कुंजी क्रेडेंशियल था।

उपयोगकर्ता एजेंट : ब्राउज़र और नेटवर्क एप्लिकेशन को एकीकृत करता है, OAuth 2.0 में क्लाइंट के रूप में एक ही उद्देश्य पर काम करता है, अर्थात्, एक तरफ, उपयोगकर्ता के साथ बातचीत करता है और उसे GUI प्रदान करता है, और दूसरी ओर, सिस्टम के साथ बातचीत करता है जो उपयोगकर्ता क्रेडेंशियल्स के साथ है ।

प्राधिकरण प्रवाह

प्रमाणीकरण प्रक्रिया शुरू करने से पहले, OAuth 2.0 की तरह, आपको तैयारी के चरणों को पूरा करने की आवश्यकता है, केवल OAuth 2.0 में हमने आवेदन पंजीकृत किया है, और WebAuth 2.0 में हम उपयोगकर्ता को पंजीकृत करते हैं। वेब प्रमाणीकरण API दो कॉल निर्दिष्ट करता है:

navigator.credentials.create - उपयोगकर्ता क्रेडेंशियल्स बनाने के लिए
navigator.credentials.get - उपयोगकर्ता क्रेडेंशियल्स की पुष्टि करता है

तदनुसार, रजिस्टर करने के लिए, आपको navigator.credentials.create पर कॉल करना होगा।

इसके परिणामस्वरूप, उपयोगकर्ता का प्रमाणीकरण विशिष्ट साइट के लिए निजी कुंजी संग्रहीत करेगा, और सार्वजनिक कुंजी को Relying Party में संग्रहीत किया जाएगा।

उसके बाद, प्रमाणीकरण प्रक्रिया इस प्रकार होगी:

“WebAuthn”. , , WebAuthn, “ ” “ ”. Relying Party Challenge. Challenge — , Code OAuth 2.0.
Relying Party Challenge. , REST API.
Authenticator- CTAP (Client to Authenticator Protocols). navigator.credentials.get c :
- Challenge
Authenticator , , .
, Authenticator .
एप्लिकेशन हस्ताक्षर किए गए डेटा को Relying Party को भेजता है।
Relying Party सार्वजनिक कुंजी का उपयोग करके डेटा को डिक्रिप्ट करता है, चैलेंज की जाँच करता है और उपयोगकर्ता को अधिकृत करता है।

उस सामग्री को ठीक करने के लिए जो हम प्रयोगशाला में काम करते हैं:

WebAuthn: लैब (Google)

WebAuthn को लागू करने के लिए, केवल http अनुरोधों के साथ, जैसा कि वितरित नहीं किया जा सकता है आपको प्रमाणीकरणकर्ता के साथ बातचीत करने के लिए ब्राउज़र एपीआई को कॉल करने की आवश्यकता है। लेकिन यहां Google खुश है, चरण-दर-चरण निर्देशों के साथ एक सैंडबॉक्स बनाया गया है: आपका पहला WebAuthn ।

काम के परिणामस्वरूप, हमें एक जेएस क्लाइंट-सर्वर एप्लिकेशन मिलता है जो फिंगरप्रिंट प्रमाणीकरण को लागू करता है। एक काम कर रहा है पर स्थित है ।

यदि आप इसे फिंगरप्रिंट सेंसर वाले स्मार्टफोन पर चलाते हैं, तो आप कार्य का परिणाम देख सकते हैं। हमेशा की तरह, पहली तैयारी - उपयोगकर्ता को पंजीकृत करें:

एक उपयोगकर्ता नाम / पासवर्ड बनाएं और फिर फिंगरप्रिंट संलग्न करें:

उसके बाद, प्रोग्राम दिखाता है कि इस फिंगरप्रिंट से कौन सी सार्वजनिक कुंजी जुड़ी हुई है:

अब आप प्रमाणीकरण स्क्रिप्ट शुरू कर सकते हैं। हमेशा की तरह, हम मानते हैं कि चरण 1 पूरा हो गया है और हम साइट पर हैं। चरण 2 पर जाने के लिए, "कोशिश करो" पर क्लिक करें। ब्राउज़र चरण 3 का प्रदर्शन करेगा और प्रमाणीकरणकर्ता के साथ बातचीत करेगा, जो चरण 4 में आपको अपनी उंगली डालने के लिए कहेगा:

और यदि पंजीकृत उंगली जुड़ी हुई है, तो चरण 5 और 6 सफलतापूर्वक पारित होंगे और चरण 7 में आवेदन फिर से संबंधित सार्वजनिक कुंजी के साथ विंडो दिखाएगा:

निष्कर्ष

इसलिए, हमने उपयोगकर्ता पहचान के लिए तीन सबसे सामान्य और आशाजनक प्रोटोकॉल की जांच की: OAuth 2.0, OpenID कनेक्ट, वेबऑन। हमने उनकी प्रयोज्यता के दायरे को समझा:

OAuth 2.0 - सोशल नेटवर्क का उपयोग करके साइटों को उपयोगकर्ताओं को पंजीकृत करने और लॉगिन करने के लिए उपयोग किया जाता है। और सामाजिक नेटवर्क से उपयोगकर्ता डेटा प्राप्त करने के लिए भी।
OpenID Connect — . OpenID Connect SSO .
WebAuthn — .

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

यह केवल शुरुआत है!

परिशिष्ट: अन्य प्रमाणीकरण प्रोटोकॉल

पूर्णता के लिए, मैं उपयोगकर्ताओं की पहचान करने के लिए उपयोग किए जाने वाले अन्य प्रासंगिक प्रोटोकॉल और तकनीकों को सूचीबद्ध करूंगा:

SAML 2.0 (सुरक्षा अभिकथन मार्कअप लैंग्वेज)

2005 के परिपक्व प्रोटोकॉल, लेकिन SSO सिस्टम के निर्माण के लिए परिदृश्यों का एक सीमित सेट है। XML- आधारित डेटा प्रारूप का उपयोग करता है। अधिक विवरण लेख में पाया जा सकता है: "कौन SAML 2.0 प्रमाणीकरण प्रोटोकॉल का उपयोग करता है"

क्रेडेंशियल मैनेजमेंट एपीआई

यह विकास वेब संगठन - डब्ल्यू 3 सी के समान संगठन द्वारा किया जाता है। क्रेडेंशियल प्रबंधन मानक आपको इसकी अनुमति देता है:

ग्राहकों की पहचान संग्रहीत करें, जो उपयोगकर्ताओं को पासवर्ड दर्ज किए बिना साइटों तक पहुंचने की अनुमति देता है, लेकिन स्टोर से पासवर्ड का उपयोग करता है।
कुछ साइटों को दर्ज करने के लिए आवश्यक खातों का चयन करें।
आपको अन्य उपकरणों पर एक डिवाइस पर दर्ज लॉगिन / पासवर्ड का उपयोग करने की अनुमति देता है।

क्रेडेंशियल मैनेजमेंट एपीआई का एक सामान्य कार्यान्वयन उदाहरण Google का पासवर्ड मैनेजर है : words.google.com

ओपन ऑथेंटिकेशन (OATH) के लिए पहल

शपथ संसाधन

OAuth 2.0-आधारित प्रोटोकॉल की एक पूरी सूची

ओपनआईडी कनेक्ट - पहले विस्तार से समीक्षा की गई
UMA 1.0 उपयोगकर्ता-प्रबंधित पहुँच (UMA) OAuth 2.0 का प्रोफ़ाइल
UA 2.0 उपयोगकर्ता-प्रबंधित पहुँच (UMA) OAuth 2.0 प्राधिकरण के लिए 2.0 अनुदान
IndieAuth W3C स्टैंडर्ड का लिंक

आधुनिक पहचान मानक: OAuth 2.0, OpenID कनेक्ट, WebAuthn