ملحوظة. ترجمة.: تشرح هذه المقالة الرائعة من قبل Okta كيفية عمل OAuth و OIDC (OpenID Connect) بطريقة بسيطة وواضحة. ستكون هذه المعرفة مفيدة للمطورين ومسؤولي النظام وحتى "المستخدمين العاديين" لتطبيقات الويب الشائعة ، والتي من المرجح أيضًا أن تتبادل البيانات السرية مع الخدمات الأخرى.
في العصر الحجري للإنترنت ، كان تبادل المعلومات بين الخدمات أمرًا سهلاً. لقد قمت ببساطة بإعطاء معلومات تسجيل الدخول وكلمة المرور الخاصة بك من خدمة إلى أخرى ، بحيث قام بإدخال حسابك وتلقي أي معلومات يحتاجها.
"أعطني حسابك المصرفي". "نحن نعد بأن كل شيء سيكون على ما يرام مع كلمة المرور والمال. هذا صريح وصادق! " * هه هه *
رعب! لا ينبغي لأحد أن يطلب من المستخدم مشاركة اسم المستخدم وكلمة المرور ، أوراق اعتماد، مع خدمة أخرى. ليس هناك ما يضمن أن المنظمة التي تقف وراء هذه الخدمة ستحافظ على أمان البيانات ولن تجمع معلومات شخصية أكثر من اللازم. قد يبدو الأمر مجنونًا ، لكن بعض التطبيقات لا تزال تستخدم هذه الممارسة!
يوجد اليوم معيار واحد يسمح لخدمة ما باستخدام بيانات أخرى بشكل آمن. لسوء الحظ ، تستخدم هذه المعايير الكثير من المصطلحات والمصطلحات ، مما يعقد فهمها. الغرض من هذه المادة هو شرح كيفية عملها باستخدام الرسوم التوضيحية البسيطة (هل تعتقد أن رسوماتي تشبه طلاء الأطفال؟ حسنًا!).
بالمناسبة ، يتوفر هذا الدليل أيضًا بتنسيق فيديو:
سيداتي سادتي ، مرحبًا بكم: OAuth 2.0
هو معيار أمان يسمح لتطبيق واحد بالحصول على إذن للوصول إلى المعلومات في تطبيق آخر. تسلسل خطوات إصدار التصريح [إذن] (أو موافقة [موافقة]) في كثير من الأحيان تفويض [تفويض] أو حتى تفويض التفويض [تفويض التفويض]. باستخدام هذا المعيار ، تسمح للتطبيق بقراءة البيانات أو استخدام وظائف تطبيق آخر نيابة عنك دون إعطائه كلمة المرور الخاصة بك. فصل!
كمثال ، لنفترض أنك اكتشفت موقعًا يسمى "Unlucky Pun of the Day" [رهيبة اليوم] وقررت التسجيل فيه لتلقي التورية اليومية على شكل رسائل نصية على الهاتف. لقد أحببت الموقع حقًا ، وقررت مشاركته مع جميع أصدقائك. بعد كل شيء ، الجميع يحب التورية المخيفة ، أليس كذلك؟
"تورية اليوم المؤسفة: هل سمعت عن الرجل الذي فقد النصف الأيسر من جسده؟ الآن هو دائما على حق! " (ترجمة تقريبية ، لأن الأصل له تورية خاصة به - ترجمة تقريبية.)
من الواضح أن الكتابة إلى كل شخص من قائمة جهات الاتصال ليست خيارًا. وإذا كنت مثلي قليلاً ، فستبذل قصارى جهدك لتجنب العمل غير الضروري. لحسن الحظ ، يمكن لـ Terrible Pun of the Day دعوة جميع أصدقائك بمفردها! للقيام بذلك ، تحتاج فقط إلى فتح الوصول إلى البريد الإلكتروني لجهات الاتصال - سيرسل الموقع نفسه دعوات إليهم (قواعد OAuth)!
"الجميع يحب التورية! - هل قمت بتسجيل الدخول بالفعل؟ "هل ترغب في السماح لموقع Terrible Pun of the Day بالوصول إلى قائمة جهات الاتصال الخاصة بك؟ - شكرًا لك! من الآن فصاعدًا ، سنرسل تذكيرات كل يوم إلى كل شخص تعرفه ، حتى نهاية الوقت! انت افضل صديق!"
- اختر خدمة البريد الإلكتروني الخاصة بك.
- إذا لزم الأمر ، انتقل إلى موقع البريد وقم بتسجيل الدخول إلى حسابك.
- امنح Terrible Pun of the Day إذنًا للوصول إلى جهات الاتصال الخاصة بك.
- العودة إلى موقع Terrible Pun of the Day.
في حال غيرت رأيك ، فإن التطبيقات التي تستخدم OAuth توفر أيضًا طريقة لإلغاء الوصول. بمجرد أن تقرر أنك لم تعد ترغب في مشاركة جهات الاتصال مع Terrible Pun of the Day ، يمكنك الانتقال إلى موقع البريد وإزالة موقع التورية من قائمة التطبيقات المعتمدة.
تدفق OAuth
لقد مررنا للتو بما يسمى عادة تدفق [تدفق] OAuth. في مثالنا ، يتكون هذا التدفق من خطوات مرئية ، بالإضافة إلى عدة خطوات غير مرئية ، حيث تتفق خدمتان على تبادل آمن للمعلومات. يستخدم المثال السابق لـ Terrible Pun of the Day تدفق OAuth 2.0 الأكثر شيوعًا ، والمعروف باسم تدفق "كود التفويض". [تدفق "رمز التفويض"].
قبل الخوض في تفاصيل كيفية عمل OAuth ، دعنا نتحدث عن معنى بعض المصطلحات:
- مالك المورد:
إنه أنت! أنت تمتلك بيانات الاعتماد الخاصة بك وبياناتك وتتحكم في جميع الأنشطة التي قد يتم إجراؤها على حساباتك. - العميل:
تطبيق (على سبيل المثال ، خدمة Terrible Pun of the Day) يريد الوصول إلى أو تنفيذ إجراءات معينة نيابةً عن مالك المورد'أ. - خادم التفويض:
التطبيق الذي يعرف مالك المورد'أ وفيه ش مالك الموردلديك حساب بالفعل. - خادم الموارد:
واجهة برمجة التطبيقات (API) أو خدمة العميل يريد استخدامه نيابة مالك المورد'أ. - إعادة توجيه URI:
الارتباط الذي خادم التفويض سيعيد التوجيه مالك الموردوبعد منح الإذن العميل'في. يشار إليه أحيانًا باسم "عنوان URL لمعاودة الاتصال". - نوع الاستجابة:
نوع المعلومات المتوقع استلامها العميل. الأكثر شيوعا نوع الاستجابة"أوم هو الرمز ، وهذا هو العميل تتوقع أن تتلقى قانون التفويض. - مجال:
هذا وصف تفصيلي للأذونات المطلوبة العميلy ، مثل الوصول إلى البيانات أو تنفيذ إجراءات معينة. - موافقة:
خادم التفويض قلنسوة نطاقاتمطلوب العميليسأل مالك المورد'أ ، هل هو مستعد لتقديم العميل'لديك الأذونات المناسبة. - معرف العميل:
يستخدم هذا المعرف للتعريف العميلعلى خادم التفويض"ه. - سر العميل:
هذه هي كلمة المرور المعروفة فقط العميل'أنت و خادم التفويض'في. يسمح لهم بمشاركة المعلومات بشكل خاص. - قانون التفويض:
رمز مؤقت مع فترة صلاحية قصيرة ، والتي العميل يوفر خادم التفويض'y في مقابل رمز الوصول. - رمز الوصول:
المفتاح الذي سيستخدمه العميل للتواصل معه خادم المواردأوم. نوع من الشارة أو البطاقة الرئيسية التي توفرها العميل'لديك إذن لطلب البيانات أو تنفيذ الإجراءات على خادم المواردنيابة عنك.
لاحظ: أحيانًا يكون خادم التخويل وخادم الموارد هما نفس الخادم. ومع ذلك ، في بعض الحالات ، قد تكون هذه خوادم مختلفة ، حتى لو لم تكن تنتمي إلى نفس المؤسسة. على سبيل المثال ، قد يكون خادم التفويض خدمة تابعة لجهة خارجية موثوق بها من قِبل خادم الموارد.
الآن بعد أن غطينا المفاهيم الأساسية لـ OAuth 2.0 ، دعنا نعود إلى مثالنا ونلقي نظرة فاحصة على ما يحدث في تدفق OAuth.
- أنت، مالك المورد، تريد تقديم خدمة Terrible Pun of the Day (العميلy) الوصول إلى جهات الاتصال الخاصة بك حتى يتمكنوا من إرسال دعوات إلى جميع أصدقائك.
- العميل يعيد توجيه المتصفح إلى الصفحة خادم التفويض'أ وتضمينه في الاستعلام معرف العميل, إعادة توجيه URI, نوع الاستجابة وواحد أو أكثر نطاقات (أذونات) يحتاجها.
- خادم التفويض يتحقق منك ، ويطلب اسم مستخدم وكلمة مرور إذا لزم الأمر.
- خادم التفويض يعرض النموذج موافقة (تأكيدات) مع قائمة الكل نطاقاتمطلوب العميلأوم. أنت توافق أو ترفض.
- خادم التفويض يعيد توجيهك إلى الموقع العميل'أ ، باستخدام إعادة توجيه URI مع قانون التفويض (قانون التفويض).
- العميل يتواصل مباشرة مع خادم التفويضأوم (تجاوز المتصفح مالك الموردأ) ويرسل بأمان معرف العميل, سر العميل и قانون التفويض.
- خادم التفويض يتحقق من البيانات ويستجيب مع رمز الوصولom (رمز الوصول).
- الآن العميل يمكن استخدام رمز الوصول لإرسال طلب إلى خادم الموارد للحصول على قائمة جهات الاتصال.
معرف العميل والسرية
قبل وقت طويل من السماح لـ Terrible Pun of the Day بالوصول إلى جهات الاتصال الخاصة بك ، أقام العميل وخادم التفويض علاقة عمل. أنشأ خادم التفويض معرّف العميل وسر العميل (يطلق عليه أحيانًا اسم التطبيق معرف и سر التطبيق) وإرسالها إلى العميل لمزيد من التفاعل داخل OAuth.
"- مرحبًا! أود أن أعمل معك! - بالتأكيد ، ليست مشكلة! إليك معرّف العميل والسرية! "
يشير الاسم إلى أن سر العميل يجب أن يظل سريًا بحيث لا يعرفه سوى العميل وخادم التفويض. بعد كل شيء ، وبمساعدته ، يؤكد خادم التفويض حقيقة العميل.
ولكن هذا ليس كل شيء ... الرجاء الترحيب بـ OpenID Connect!
تم تصميم OAuth 2.0 فقط من أجل ملفات تفويض - لتوفير الوصول إلى البيانات والوظائف من تطبيق إلى آخر. (OIDC) عبارة عن طبقة رقيقة أعلى OAuth 2.0 تضيف تفاصيل تسجيل الدخول والملف الشخصي للمستخدم الذي قام بتسجيل الدخول إلى الحساب. غالبًا ما يشار إلى تنظيم جلسة تسجيل الدخول باسم المصادقة [المصادقة]، ومعلومات حول المستخدم الذي قام بتسجيل الدخول إلى النظام (على سبيل المثال ، حول مالك المورده) ، - بيانات شخصية [هوية]. إذا كان خادم التخويل يدعم OIDC ، فيتم الإشارة إليه أحيانًا باسم مزود البيانات الشخصية [مقدم الهوية]لأنه يوفر العميلمعلومات عن مالك المورد"ه.
يتيح لك OpenID Connect تنفيذ سيناريوهات حيث يمكن استخدام تسجيل دخول واحد في تطبيقات متعددة - يُعرف هذا النهج أيضًا باسم علامة واحدة على (SSO). على سبيل المثال ، قد يدعم أحد التطبيقات تكامل SSO مع الشبكات الاجتماعية مثل Facebook أو Twitter ، مما يسمح للمستخدمين باستخدام حساب لديهم بالفعل ويفضلون استخدامه.
يبدو التدفق (التدفق) OpenID Connect هو نفسه كما في حالة OAuth. الاختلاف الوحيد هو أن النطاق المحدد المستخدم في الطلب الأساسي هو openid، - أ العميل في النهاية رمز الوصولو رمز الهوية.
تمامًا كما هو الحال في تدفق OAuth ، رمز الوصول في OpenID Connect ، هذه قيمة غير واضحة العميل'في. من وجهة نظر العميل'أ رمز الوصول يمثل سلسلة من الأحرف التي يتم تمريرها مع كل طلب إلى خادم الموارد'y ، الذي يحدد ما إذا كان الرمز المميز صالحًا أم لا. رمز الهوية يمثل شيئًا مختلفًا تمامًا.
رمز المعرف هو JWT
رمز الهوية هي سلسلة أحرف منسقة بشكل خاص تعرف باسم JSON Web Token أو JWT (أحيانًا يتم نطق رموز JWT المميزة مثل "jots"). بالنسبة للمراقبين الخارجيين ، قد تبدو نظرية الحرب العادلة وكأنها هراء غير مفهوم ، ولكن العميل يمكن استخراج معلومات مختلفة من JWT ، مثل المعرف واسم المستخدم ووقت تسجيل الدخول وتاريخ انتهاء الصلاحية رمز الهوية- وجود محاولات للتدخل في عمل JWT. البيانات بالداخل رمز الهويةيتم استدعاء التطبيقات [مطالبات].
في حالة OIDC ، هناك أيضًا طريقة قياسية يتم من خلالها العميل قد تطلب معلومات إضافية عن الفرد [هوية] من خادم التفويضأ ، على سبيل المثال ، استخدام عنوان بريد إلكتروني رمز الوصول.
تعرف على المزيد حول OAuth و OIDC
لذلك ، قمنا بمراجعة كيفية عمل OAuth و OIDC بإيجاز. هل أنت مستعد للحفر أعمق؟ فيما يلي موارد إضافية لمساعدتك في معرفة المزيد حول OAuth 2.0 و OpenID Connect:
كما هو الحال دائما، لا تتردد في التعليق. لمواكبة آخر أخبارنا ، اشترك في и اوكتا للمطورين!
PS من المترجم
اقرأ أيضًا على مدونتنا:
- «"؛
- «"؛
- «"؛
- «".
المصدر: www.habr.com