يحتوي OpenID Connect على مواصفات ، وهناك برامج تعليمية ومقالات على المحور وليس على المحور من غير المجدي وضع تعليمات أخرى خطوة بخطوة ، من الحيرة العميقة إلى العمل من خلال التفويض والمصادقة. مهمة النص أدناه مختلفة ، لوصف الأفكار الكامنة في المواصفات (هناك أكثر من واحد).
لن أقفز على موضوع المقالة على الفور ، لكنني سأبدأ بأشياء بسيطة والعديد من الأشياء الواضحة. سأستمر في طريقة تطويرهم وما اختتموه وفقًا لمتطلبات العملاء. سأقترب منه تاريخيا ، أي بالطريقة التي ولد بها.
1.
المهمة الدنيا هي ببساطة عدم السماح لأي شخص بالوصول إلى أي من موارده. نقوم بإغلاقه باستخدام اسم المستخدم / كلمة المرور ، الذي يعرف الزوج الصحيح من أسماء المستخدمين وكلمات المرور ، وسيتم توجيهه إلى المورد الذي لا يعرفه. هذا الشيء يسمى المصادقة ، لأنه لا يمكنك فقط استخدام تسجيلات الدخول باستخدام كلمات المرور (رمز SMS ، على سبيل المثال ، أو مفتاح USB للأجهزة) ، ولكن هذه التفاصيل ليست ضرورية لموضوعنا. سأحذف أيضًا الفقرة الإلزامية حول خطر نقل كلمات المرور عبر الإنترنت في شكل مفتوح ، والتي نكره جميعًا مصادقة الوصول الأساسي لها .
من الأفضل ملاحظة هذا: لا يحب أي من المستخدمين إدخال معلومات تسجيل الدخول باستخدام كلمات المرور. الرموز في الرسائل القصيرة ليست أفضل ، وكراهية مفاتيح USB ببساطة على الإطلاق. من أجل عدم إجبار المستخدم على إدخال تسجيل دخول بكلمة مرور لكل طلب ، يرسل الخادم استجابة له سطرًا من الثرثرة يسمى مفتاح الجلسة . وبعد ذلك يتمسك هذا المفتاح بكل طلب خادم من قبل العميل (عادةً باستخدام رأس HTTP ، ولكن هذا ليس ضروريًا) ، ويتحقق الخادم مما إذا كان لديه مثل هذه الجلسة.
جلسة بمفتاح - الظواهر ، بحكم تعريفها ، مؤقتة ، تكون النسبة الذهبية طوال مدة الجلسة تقريبًا "أثناء فتح علامة تبويب المتصفح ، ولكن ليس أكثر من يوم واحد"
2.
لقد سمحوا لأي شخص بالدخول - هذا جيد. الآن أنت بحاجة إلى فهم بالضبط من تركنا. وليس فقط لاستنتاج ما أدخله كاسم في الزاوية اليمنى العليا ، ولكن أيضًا لتحديد ما يسمح له بالدخول وما لا.
وكل هذا يسمى - إذن . وأنا لست متأكدًا منك ، لكني أخلط بينه وبين المصادقة طوال الوقت. لكي لا نخلط - قاعدة ذات ذاكرة نسبية ، "تفويض" - من كلمات "مؤلف" ، "مؤلف" يكتبون على أغلفة الكتب ، ولا يكتبون أبدًا "عضوًا صالحًا في اتحاد الكتاب" هناك. المؤلف دائما شخص محدد جدا. إذن التفويض هو عملية عندما نفهم من أطلقناه بالضبط عن طريق تسجيل الدخول وكلمة المرور.
3.
حسنًا لدينا موقع ، هناك شيء سري على الموقع ، عند مدخل الجزء السري نطلب كلمة مرور ، وكل واحد يظهر فقط أسراره ، ولا نظهر الغرباء. الحياة لا تقف مكتوفة الأيدي ، ولدينا موقع آخر. وهنا نواجه المشكلة مرة أخرى من النقطة 1 ، لا أحد يحب إدخال أسماء المستخدمين وكلمات المرور! يمكنك الجمع بين قاعدة المستخدمين وهذا سيوفر عليهم من الاضطرار إلى التسجيل مرتين ، ولكن كيفية حفظهم من إعادة إدخال تسجيل الدخول وكلمة المرور عند المدخل؟ بالنظر إلى وجود شيء مثل سياسة الأصل نفسه (وتقع مواقعنا ، بالطبع ، على نطاقات مختلفة ، فإن ملفات تعريف الارتباط بمفتاح جلسة غير مرئية لبعضها البعض)؟ هنا ، ولأهمية اللحظة ، سأبدأ نقطة جديدة.
4.
SSO ، الدخول الموحد - مهما كان التطبيق ، Microsoft Kerberos أو SAML أو أي شيء OAuth 2.0 ، والذي تم إنشاء OpenID Connect فوقه ، والذي أكتب عنه هنا ، في الواقع ، يوجد دائمًا نفس الشيء تحت غطاء المحرك: هناك خادم منفصل إذن ، وأي شخص يريد تخويل مستخدم يعيد توجيه المستخدم إليه. إذا كان المستخدم مفوضًا بالفعل ، يتم التقاط الجلسة ، ويعود على الفور من خادم التفويض ويصل إلى حيث يريد. إذا لم يكن مرخصًا ، يحل خادم التخويل هذه المشكلة بأفضل ما يمكن ، عن طريق طلب اسم مستخدم بكلمة مرور ، كقاعدة ، وإذا نجح ، فإنه يعيد المستخدم.
علاوة على ذلك ، فإن SAML في الوقت الحالي الحل ، إذا جاز التعبير ، عفا عليه الزمن. و Kerberos بشكل عام هو سحر Microsoft مغلق تمامًا منفصل تمامًا يتجاوز نطاق بروتوكول HTTP. حسنًا ، سنركز عليه. ثم نصل إلى المشكلة التالية.
يوجد بالفعل سيناريو عمل مفهوم - في أي موقف غير مفهوم ، أرسل المستخدم إلى خادم التفويض ، ودعه يقرر ما يجب عليه فعله وإرجاع إجابة جاهزة. ولكن كيف يخبر خادم التفويض ذلك الخادم الآخر أن المستخدم مخول؟ نعود هنا مرة أخرى إلى أفكار الفقرة الأولى ، أي مفتاح الجلسة. دعنا نعود إلى الأساسيات: إن وجود مفتاح جلسة هو علامة على التفويض ، ومفتاح الجلسة نفسه يفتح الباب أمام معلومات المستخدم ، ولن تصدق ذلك ، إلى معلومات الجلسة. لذا فإن خادم المصادقة يخول ويعطي مفتاح الجلسة لخادم آخر.
الآن ، ومع ذلك ، لم يعد يسمى مفتاح الجلسة ، ولكن رمز مميز .
بتعبير أدق ، (وفقًا لبروتوكول OAuth 2.0 ، الذي تتم كتابة OpenID Connect فوقه) ، هذان رمزان مميزان في وقت واحد - Access Token ، لربطه بجميع الطلبات كمفاتيح للأجداد ، و Refresh Token ، لتحديث Access Token عندما يخرج.
لتلخيص المجموع الفرعي. بدلاً من مطالبة المستخدم باسم المستخدم وكلمة المرور ، يرسله الخادم إلى خادم آخر ، خادم تفويض منفصل. يقوم بكل العمل ، ثم يعطي الرموز الأولى. في هذا السيناريو بالضبط ، يتم السماح بالتطبيقات والجوّال وأحيانًا سطح المكتب. ، فهي لا تجري أي عمليات إعادة توجيه ، بل ترسل فقط خادم تفويض JSON باستخدام اسم مستخدم وكلمة مرور ، ويرسلها الرموز المميزة استجابةً.
يمكن لتطبيقات الهاتف المحمول وسطح المكتب القيام بذلك. لسبب ما يعتبرون أكثر أمانًا من الويب ، لكن الويب لديه حياة أكثر تعقيدًا.
6.
من ناحية ، ليس الأمر أكثر تعقيدًا ، ولكنه على العكس أبسط. يمكنك إجراء إعادة توجيه ولا تزعج نفسك بتقديم نموذج تسجيل الدخول وكلمة المرور. من ناحية أخرى ، أنا حقاً لا أريد سحب الرموز المميزة من خلال المتصفح بشكل واضح. هذا أمر مثير للاشمئزاز تقريبًا مثل كلمة المرور غير المشفرة في مصادقة الوصول الأساسية . لكن لا أحد يريد تكرار هذا الخطأ الرهيب القديم.
لم يكن هناك حل للمشكلة بحيث تكون أنيقة للغاية ، ولكنها تعمل. أولاً ، كل شيء يسير كالمعتاد ، يتحول إلى إذن ، إذن نفسه. بعد ذلك ، عندما يحين وقت العودة باستخدام الرموز ، تحدث إعادة التوجيه العكسية. ولكن بدلاً من الرموز المميزة ، يتم إرفاق رمز لمرة واحدة بعنوان الإرجاع. تم إنشاء الرمز لمرة واحدة فقط بواسطة خادم التفويض في هذه اللحظة بالذات. لديه حياة قصيرة جدا. بعد أن تلقى بالكاد رمزًا لمرة واحدة ، يجب أن يقوم خادم آخر برفع التنانير ، وتضخيم عينيه ، والاندفاع إلى خادم التفويض مرة أخرى ، من أجل تلقي الرموز المرغوبة من الرمز لمرة واحدة.
هناك مورد خاص لرحلة برمز للرموز المميزة على خادم التفويض. يقبل ، عن طريق المواصفات ، لا GET ، ولكن POST. يلمح لنا هذا بطريقة أو بأخرى إلى أن هذا الطلب لا يجب أن يتم من المتصفح ، ولكن من خادم إلى خادم.
لنفس السبب ، في أي خادم ترخيص CORS يحترم نفسه ، يُحظر طلبات POST.
7.
بالمناسبة ، هل ما زلت تتذكر المصادقة والتفويض؟ المصادقة هي عندما يُسمح لشخص ما ببساطة بالدخول عن طريق تسجيل الدخول وكلمة المرور ، أو غير مسموح به. والتفويض عندما يبدأ بالفعل ، يبدأون في فهم من بدأوا بالضبط.
هل تتذكر بروتوكول OAuth 2.0 ؟ لقد ذكرت ذلك عدة مرات أعلاه ، كنوع من الأساس لـ OpenID Connect.
هل تتذكر OpenID Connect ؟ هذا المقال هو فقط البكم.
لذا ، OAuth 2.0 هو المصادقة. الإجراء بأكمله الموصوف سابقًا والمربك قليلاً مع ثلاثة مشاركين ، وكلمة مرور ورمز ورمز مميز ، كل شيء يتعلق بالمصادقة ، فقط حول السماح لشخص ما بالعمل في مكان ما. بروتوكول OAuth 2.0.
OpenID Connect هو إذن. أي أنه يضيف إلى OAuth تلك الأجزاء حيث يتبين من تركوها.
للقيام بذلك ، تتم إضافة واحد آخر إلى قائمة الرموز المميزة ، ويسمى ID Token . من المحتمل أن يتفاجأ أولئك الذين يتبعون الرابط بعدم رؤية أي شيء حول أي معرف الرمز المميز عليه. دع المفاجأة لا تتحول إلى خوف ، معرف ID هذا هو JWT الذي تم إرجاعه كدمية متداخلة ذات ترميز base64 في نفس JSON مثل Access Token و Refresh Token. على أي حال ، كل ما تريد معرفته عن المستخدم موجود فيه.
وهناك أيضًا مورد خاص على خادم التفويض يسمى userinfo ، حيث يمكنك النقر على Access Token والحصول على نفس JSON كرد فعل في Token ID. ولكن لماذا تكون هناك حاجة إذا كان معرف الرمز المميز موجودًا بالفعل؟ سؤال لمؤلفي المواصفات.
يحتوي OpenID Connect أيضًا على وصف لمختلف مجالات معلومات المستخدم. كيف يمكنني الحصول على هذه المعلومات ، مباشرة أثناء التفويض أو في أي وقت بعد ذلك. ووصف لكيفية ومتى سيسمح لك المستخدم باستخدام هذه المعلومات.
أو لا تسمح بذلك. لذلك ، باختصار ، تم تصميم OpenID Connect 1.0.
8.
القليل من بهرج في البروتوكول. آمل أن تكون قد سئمت من قراءة المقالة في الوقت الحالي ، حتى لا تولي اهتمامًا كبيرًا لهذا العنصر ، فقط من خلال تمريره عبر العين. هنا سأذكر المعلمات الموجودة في المواصفات ، وتحمل بعض الحمل الدلالي ، لكنها لا تتعلق مباشرة بتنفيذ الفكرة نفسها. بشكل أساسي ، يضيفون الأمان ، أو يسمحون لك ببساطة بنقل بعض المعلومات من أحد المشاركين في العملية إلى آخر ، إذا لزم الأمر.
معرف العميل وسر العميل . العميل بلغة بروتوكول OpenID Connect ليس متصفحًا على الإطلاق ، ولكنه الخادم الآخر الذي يحتاج إلى تفويض المستخدم. لنفترض أن لديك موقع ويب ، وتريد إرفاق تفويض عصري إليه عبر Facebook. ومن خلال googol. وليس من المألوف عبر Twitter. تطبيق البروتوكول في المدونة لن يكون كافيا. ستحتاج أيضًا إلى التسجيل في Facebook ، وفي Google ، وفي Twitter ، ولكن ليس كمستخدم ، ولكن كعميل يمكنه ، كخادم ، استخدام تفويضه. عند التسجيل ، ستتلقى هوية عميل وسر عميل من الفيسبوك الشرطي. وعند طلب التفويض ، من بين أشياء أخرى ، أرسل معرف العميل. وعندما تستخدم رمزًا لمرة واحدة لرمز مميز ، سيطلب منك Client Secret أيضًا.
إعادة توجيه URI . كل شيء بسيط هنا. عند إرسال مستخدم إلى Facebook مشروط لتسجيل الدخول ، تحتاج إلى إخبار Facebook بمكان إرجاع الرموز والرموز المميزة إليه بعد التفويض. بالطبع ، ما زلت تعطيه معرف العميل الخاص بك. ولكن يسمح لك Redirect URI منفصل بإعادة التوجيه بعد تخويل مستخدمين مختلفين لصفحات مختلفة ، على سبيل المثال المشرفون في لوحة المشرف ، والمستخدمين العاديين إلى صفحاتهم الشخصية. عملي. بالإضافة إلى ذلك ، تعد القائمة المسموح بها لمعرفات URI المحتملة المحددة في إعدادات العميل على facebook الشرطي أمانًا إضافيًا.
النطاق . هذه قائمة بما يريد الخادم معرفته عن المستخدم من خادم التفويض. القيم في القائمة مفصولة بمسافات ، يجب أن يكون openid إلزاميًا بينها ، ثم قراءة المواصفات.
الدولة . هل تتذكر الرمز لمرة واحدة ، الذي يتم من خلاله إصدار الرموز المميزة ، مثل تذكرة في قائمة انتظار إلكترونية؟ لذا ، فإن الحالة هي رمز ، على العكس ، إذا أصدر خادم التفويض رمزًا إلى خادم آخر بحيث يعيده قريبًا ، فإن هذه الحالة تمنح خادم تفويض آخر إلى ذلك الخادم لإعادته عند إعادة التوجيه. هو مطلوب ، كما أفهمه ، إذا تمكن خادم آخر بالفعل من إنشاء جلسة خاصة به حتى لا تضيع في جميع عمليات إعادة التوجيه هذه.
هناك معلمات أخرى ، مثل نوع طلب التفويض وعمر الرمز المميز ، ولكن لفهم سبب عدم حاجتك إليها.
في الختام. آمل حقًا أن القراءة غير المدروسة والمركزة للنص أعلاه في مكان ما قد ساعدتك على التقاط الأفكار التي تكمن وراء بعض بروتوكولات التحكم في الوصول الحديثة. ولكن بدء التنفيذ ، أو لمجرد تكوين واحد منهم ، افتح المواصفات ، واعثر على برنامج تعليمي جيد ، واتبع بعناية كل كلمة وكل حرف. ودع فهم الأفكار يوقظ الحدس بداخلك. والحدس ، دعه يعضك في التاج في كل مرة تفوت فيها معلمة ليست مهمة جدًا للوهلة الأولى ، أو مكانًا ، واترك هذا حفرة للأيدي الصغيرة المرحة المتعرقة.
تذكر أن هذا هو نفس الأمان ، وقواعده ، بغض النظر عن مدى غباءها ولا معنى لها قد تبدو ، مكتوبة بالدم. حسنًا ، ربما ليس بالدم ، فهو ليس مقياسًا للسلامة في المسبك ، بعد كل شيء ، لكن المال والسمعة أمر مؤكد ، والمال والسمعة ليسا أيضًا الأشياء التي يجب عليك التخلص منها بسهولة.
بفضل JM لحقيقة أن النص الذي قرأته كان أفضل بكثير من النص الذي كتبته.
حظاً طيباً ولا تنس تجديد شهاداتك في الوقت المحدد.