تقريبا. العابرة. : يشرح منشور مدونة Okta الرائع OAuth و OIDC (OpenID Connect) كيف يعمل. ستكون هذه المعرفة مفيدة للمطورين ومسؤولي النظام وحتى "المستخدمين العاديين" لتطبيقات الويب الشائعة التي من المرجح أن تتبادل أيضًا البيانات الحساسة مع خدمات أخرى.في العصر الحجري للإنترنت ، كان تبادل المعلومات بين الخدمات أمرًا سهلاً. لقد قمت ببساطة بإعطاء اسم المستخدم وكلمة المرور الخاصة بك من خدمة إلى أخرى بحيث أدخلت حسابك واستلمت أي معلومات تحتاجها.
"قدم حسابك المصرفي". "نحن نعد بأن كل شيء سيكون على ما يرام مع كلمة المرور والمال. هذا بصراحة صادق! "رعب! لا يجب على أي شخص مطالبة مستخدم بمشاركة اسم المستخدم وكلمة المرور الخاصة بهم ، وبيانات
اعتمادهم ، مع خدمة أخرى. ليس هناك ما يضمن أن المؤسسة التي تقف وراء هذه الخدمة سوف تحتفظ بالبيانات آمنة ولن تجمع معلومات شخصية أكثر من اللازم. قد يبدو وحشيًا ، لكن بعض التطبيقات لا تزال تستخدم هذه الممارسة!
يوجد اليوم معيار واحد يسمح لإحدى الخدمات باستخدام بيانات أخرى بأمان. لسوء الحظ ، تستخدم هذه المعايير الكثير من المصطلحات والمصطلحات ، مما يعقد فهمهم. الغرض من هذه المادة هو شرح كيفية تعاملها مع الرسوم التوضيحية البسيطة (هل تعتقد أن رسوماتي تشبه رسم الطفل؟ حسنًا ، حسنًا!).
بالمناسبة ، يتوفر هذا الدليل أيضًا بتنسيق الفيديو:
سيداتي سادتي ، لقاء: OAuth 2.0
OAuth 2.0 هو معيار أمان يسمح لأحد التطبيقات بالحصول على إذن للوصول إلى المعلومات في تطبيق آخر. غالبًا ما تسمى سلسلة الخطوات لإصدار إذن
(إذن )
التخويل أو
التفويض المفوض . باستخدام هذا المعيار ، تسمح لأحد التطبيقات بقراءة البيانات أو استخدام وظائف تطبيق آخر نيابة عنك دون إخبار كلمة المرور الخاصة بك. الدرجة!
على سبيل المثال ، لنفترض أنك عثرت على موقع يسمى "
رهيبة التورية اليوم" وقررت التسجيل فيه لتلقي التورية اليومية في شكل رسائل نصية على هاتفك. لقد أعجبك الموقع حقًا ، وقررت مشاركته مع جميع أصدقائك. بعد كل شيء ، التورية الرهيبة مثل الجميع ، أليس كذلك؟
"التورية غير الناجحة اليوم: هل سمعت عن رجل فقد نصفه الأيسر من جسده؟" الآن هو على حق دائمًا! "(ترجمة تقريبية ، نظرًا لأن النص الأصلي له ترجمات خاصة به ، - الترجمة التقريبية.)من الواضح أن الكتابة لكل شخص من قائمة جهات الاتصال ليست خيارًا. وإذا كنت مثلي قليلاً ، فسوف تفعل أي شيء لتجنب العمل غير الضروري. لحسن الحظ ، يمكن لـ Pun of the Day أن يدعو جميع أصدقائك بمفرده! للقيام بذلك ، ما عليك سوى منحه حق الوصول إلى البريد الإلكتروني الخاص بجهات الاتصال - حيث سيقوم الموقع نفسه بإرسال دعوات لهم (محركات OAuth)!
"الكل يحب التورية!" - بالفعل تسجيل الدخول؟ - هل ترغب في مشاركة موقع Terrible Pun of the Day مع قائمة جهات الاتصال الخاصة بك؟ - شكرا! الآن ، كل يوم سوف نرسل رسائل تذكير إلى كل شخص تعرفه حتى نهاية الوقت! أنت أفضل صديق! "- اختيار خدمة البريد الإلكتروني الخاص بك.
- إذا لزم الأمر ، انتقل إلى موقع البريد وتسجيل الدخول إلى حسابك.
- منح رهيبة التورية اليوم إذن للوصول إلى جهات الاتصال الخاصة بك.
- العودة إلى موقع الرعب التورية اليوم.
في حالة تغيير رأيك ، فإن التطبيقات التي تستخدم OAuth توفر أيضًا طريقة لإلغاء الوصول. بعد أن قررت أنك لم تعد ترغب في مشاركة جهات الاتصال مع Terrible Pun of Day ، يمكنك الانتقال إلى موقع البريد وحذف الموقع من التورية من قائمة التطبيقات المعتمدة.
ستريم OAuth
لقد مررنا للتو بما يسمى عادة
بتيار [تدفق] OAuth. في مثالنا ، يتألف هذا التدفق من خطوات مرئية ، بالإضافة إلى العديد من الخطوات غير المرئية ، حيث يتفق خدمتان على تبادل آمن للمعلومات. يستخدم المثال السابق لـ Terrible Pun of the Day تيار OAuth 2.0 الأكثر شيوعًا ، والمعروف باسم
تدفق "كود التفويض" .
قبل الخوض في تفاصيل OAuth ، دعونا نتحدث عن معنى بعض المصطلحات:
- مالك المورد :
هذا انت! أنت تمتلك بيانات الاعتماد الخاصة بك وبياناتك وتدير جميع الإجراءات التي يمكن تنفيذها مع حساباتك. - العميل :
تطبيق (على سبيل المثال ، خدمة Terrible Pun of the Day) التي ترغب في الوصول إلى أو تنفيذ إجراءات معينة نيابة عن مالك المورد . - خادم التخويل :
أحد التطبيقات التي تعرف مالك المورد وفيه مالك الحساب لديه حساب بالفعل. - خادم الموارد :
واجهة برمجة التطبيقات (API) أو الخدمة التي يريد العميل استخدامها نيابة عن مالك المورد . - إعادة توجيه URI :
الرابط الذي يعيد توجيه خادم التخويل من خلاله " مالك المورد " إلى "بعد منح إذن العميل ". يطلق عليه أحيانا عنوان رد الاتصال. - نوع الاستجابة :
نوع المعلومات التي يتوقع العميل استلامها. نوع الاستجابة الأكثر شيوعًا هو الكود ، أي يتوقع العميل استلام كود التفويض . - النطاق :
هذا وصف مفصل للأذونات التي يحتاجها العميل ، مثل الوصول إلى البيانات أو تنفيذ إجراءات معينة. - الموافقة :
يأخذ خادم التخويل النطاقات المطلوبة من قبل العميل ويسأل مالك المورد إذا كان مستعدًا لمنح العميل الأذونات المناسبة. - معرف العميل :
يتم استخدام هذا المعرف لتعريف العميل على خادم التخويل . - سر العميل :
هذه كلمة مرور معروفة فقط للعميل وخادم التخويل . انها تسمح لهم لتبادل المعلومات سرا. - رمز التفويض :
رمز مؤقت قصير الأجل يوفره العميل لخادم التخويل في مقابل الحصول على رمز الوصول . - رمز الوصول :
المفتاح الذي سيستخدمه العميل للاتصال بخادم الموارد . هذه عبارة عن بطاقة أو بطاقة مفتاح تمنح العميل الإذن لطلب البيانات أو تنفيذ إجراءات على Resource Server نيابة عنك.
ملاحظة : في بعض الأحيان يكون خادم التخويل وخادم الموارد هما نفس الخادم. ومع ذلك ، في بعض الحالات ، قد تكون هذه خوادم مختلفة ، ولا تنتمي حتى لنفس المؤسسة. على سبيل المثال ، قد يكون خادم التخويل خدمة تابعة لجهة خارجية يثق بها "خادم الموارد".
الآن وقد أصبحنا على دراية بالمفاهيم الأساسية لـ OAuth 2.0 ، دعنا نعود إلى مثالنا ونلقي نظرة فاحصة على ما يحدث في ساحة مشاركات OAuth.
- أنت ، مالك المورد ، ترغب في تزويد لعبة الكلمات الرهيبة ( العميل ) بحق الوصول إلى جهات الاتصال الخاصة بك حتى يتمكن من إرسال دعوات إلى جميع أصدقائك.
- يعيد العميل توجيه المستعرض إلى صفحة خادم التخويل ويتضمن معرف العميل وإعادة توجيه URI ونوع الاستجابة ونطاق واحد أو أكثر (أذونات) يحتاجه في الطلب.
- يتحقق خادم التخويل ، إذا لزم الأمر ، من طلب اسم مستخدم وكلمة مرور.
- يعرض خادم التخويل نموذج موافقة مع قائمة بجميع النطاقات التي طلبها العميل . أنت توافق أو ترفض.
- يعيد خادم التخويل توجيهك إلى موقع العميل باستخدام Redirect URI مع رمز التخويل .
- يتصل العميل مباشرة مع خادم التخويل (تجاوز مستعرض مالك المورد ) ويرسل بشكل آمن معرف العميل وسرية العميل ورمز التفويض .
- يتحقق خادم التخويل من صحة البيانات ويستجيب باستخدام رمز الوصول .
- يمكن للعميل الآن استخدام Access Token لإرسال طلب إلى Resource Server من أجل الحصول على قائمة جهات اتصال.
هوية العميل والسرية
قبل فترة طويلة من سماحك لـ Terrible Pun of the Day بالوصول إلى جهات الاتصال الخاصة بك ، أنشأ العميل وخادم التخويل علاقة عمل. قام خادم التخويل بإنشاء معرف العميل وسرية العميل (يطلق عليه أحيانًا
معرف التطبيق وسرية التطبيق ) وإرسالهما إلى العميل لمزيد من التفاعل داخل OAuth.
"- يا! أود أن أعمل معك! - نعم لا شك! هنا معرف العميل والسرية! "يشير الاسم إلى أنه ينبغي الحفاظ على سرية عميل العميل بحيث يعرفه العميل وخادم التخويل فقط. في الواقع ، إنه بفضل مساعدته يؤكد خادم التخويل حقيقة العميل.
ولكن هذا ليس كل شيء ... الرجاء الترحيب OpenID Connect!
تم تصميم OAuth 2.0
للترخيص فقط - لتوفير الوصول إلى البيانات والميزات من تطبيق إلى آخر.
OpenID Connect (OIDC) عبارة عن طبقة رفيعة أعلى OAuth 2.0 تضيف معلومات حول اسم المستخدم والملف الشخصي للمستخدم الذي قام بتسجيل الدخول إلى الحساب. غالبًا ما تسمى مؤسسة جلسة تسجيل الدخول
بالمصادقة ، وتسمى المعلومات المتعلقة بالمستخدم الذي قام بتسجيل الدخول (أي ، حول
مالك المورد )
الهوية . إذا كان خادم التخويل يدعم OIDC ، فإنه يطلق عليه أحيانًا
موفر الهوية لأنه يزود
العميل بمعلومات عن
مالك المورد .
يسمح لك OpenID Connect بتنفيذ سيناريوهات عندما يمكن استخدام تسجيل دخول واحد في العديد من التطبيقات - يُعرف هذا النهج أيضًا باسم
الدخول الموحد (SSO). على سبيل المثال ، يمكن للتطبيق أن يدعم تكامل SSO مع الشبكات الاجتماعية مثل Facebook أو Twitter ، مما يسمح للمستخدمين باستخدام حساب لديهم بالفعل ويفضلون استخدامه.
يبدو تدفق OpenID Connect كما هو الحال مع OAuth. الاختلاف الوحيد هو أنه في الطلب الأولي ، يكون النطاق المحدد المستخدم
openid ، ويتلقى
العميل في النهاية كلاً من
رمز الوصول openid المعرّف .
تمامًا كما هو الحال في دفق OAuth ، فإن
Access Token في OpenID Connect هي قيمة لا يفهمها
العميل . من وجهة نظر
العميل ، يمثل
رمز الوصول سلسلة معينة من الأحرف التي يتم إرسالها جنبًا إلى جنب مع كل طلب إلى
Resource Server ، والذي يحدد ما إذا كان الرمز المميز صالحًا أم لا.
رمز معرف هو مختلف تماما.
رمز الهوية هو JWT
رمز معرف هو سلسلة أحرف منسقة بشكل خاص تعرف باسم JSON Web Token أو JWT
(في بعض الأحيان يتم تمييز الرموز المميزة لـ JWT باسم "jots") . بالنسبة للمراقبين الخارجيين ، قد تبدو JWT غير معروفة ، ولكن يمكن
للعميل استخراج معلومات متنوعة من JWT ، مثل المعرف واسم المستخدم ووقت تسجيل الدخول إلى الحساب وتاريخ انتهاء صلاحية
رمز الهوية ومحاولات التدخل في JWT. تسمى البيانات الموجودة داخل
معرف الرمز مطالبة .
في حالة OIDC ، هناك أيضًا طريقة قياسية يمكن من خلالها
للعميل طلب معلومات
هوية إضافية من
خادم التخويل ، على سبيل المثال ، عنوان بريد إلكتروني باستخدام
رمز الوصول .
تعرف على المزيد حول OAuth و OIDC.
لذلك ، استعرضنا لفترة وجيزة كيف تعمل OAuth و OIDC. على استعداد لحفر أعمق؟ فيما يلي موارد إضافية لمساعدتك في معرفة المزيد حول OAuth 2.0 و OpenID Connect:
كالعادة ، لا تتردد في التعليق. لمواكبة أحدث الابتكارات لدينا ، اشترك في Okta for
Twitter و
YouTube للمطورين!
PS من المترجم
اقرأ أيضًا في مدونتنا: