مهمة المصادقة
تمت مواجهة مشكلة الترخيص في عشرات الخدمات منذ عدة سنوات - في بداية " عصر نشر المنولث ". تم حل هذه المشكلة مع خدمة جديدة تسمى Auth. ساعد في تنفيذ مصادقة سلسة عبر خدمات متنوعة وترحيل بيانات المستخدم إلى قواعد بيانات منفصلة.
لخدمة المؤلفين ثلاث مهام رئيسية:
- نقطة مصادقة واحدة (SSO) لجميع خدمات النظام . لا تخزن الخدمات بيانات الاعتماد ، ولكن ثق في ذلك لخدمة واحدة مخصصة.
- الوصول الآمن والحبيبي إلى الموارد . آمن لأن كلمات المرور مخزنة في مكان واحد وتكون آمنة قدر الإمكان. دقيق ، حيث يمكن لمالكي الخدمة تكوين الوصول إلى الموارد كما يريدون ، استنادًا إلى البيانات التي تأتي من خدمة المصادقة.
- . , , .
الإصدار الأول من Auth هو جزء من متراصة. يستخدم البروتوكول الخاص به للتواصل مع الخدمات. كان مثل هذا "المخطط" ضروريًا في تلك اللحظة ، ولكن بعد عدة سنوات من العمل ظهرت مشاكل.
Auth هو جزء من متراصة . وبالتالي ، فإن الخدمة مرتبطة بدورة الإصدار ، مما يجعل من المستحيل التطوير والنشر بشكل مستقل. بالإضافة إلى ذلك ، سيتعين عليك نشر الوحدة الكاملة إذا أردت نشر المصادقة ، على سبيل المثال ، عند توسيع نطاق خدمة.
يعتمد Dodo IS على Auth . في التطبيق القديم ، تستدعي الخدمات الخارجية Auth على كل إجراء مستخدم للتحقق من صحة البيانات المتعلقة به. يمكن أن يتسبب هذا الربط الضيق في توقف Dodo IS بأكمله عن العمل إذا تعطلت Auth لسبب ما.
المصادقة تعتمد على Redis... علاوة على ذلك ، فهو قوي جدًا - سيؤدي عطل Redis إلى سقوط Auth. نحن نستخدم Azure Redis ، حيث تبلغ اتفاقية مستوى الخدمة المنصوص عليها 99.9٪. هذا يعني أن الخدمة قد تكون غير متاحة لمدة تصل إلى 44 دقيقة شهريًا. مثل هذا التوقف غير مسموح به.
يستخدم التنفيذ الحالي لـ Auth بروتوكول المصادقة الخاص به دون الاعتماد على المعايير . في معظم خدماتنا ، نستخدم C # (إذا كنا نتحدث عن الخلفية) وليس لدينا مشاكل في صيانة المكتبة لبروتوكولنا. ولكن إذا ظهرت الخدمات في Python أو Go أو Rust فجأة ، فإن تطوير ودعم المكتبات لهذه اللغات سيستغرق وقتًا إضافيًا وسيحدث تعقيدًا إضافيًا.
يستخدم Auth الحالي نظام التحكم في الوصول المستند إلى الأدوار ، والذي يعتمد على الأدوار... عادة ، يتم منح الدور حق الوصول الكامل إلى خدمة معينة ، بدلاً من الارتباط بوظيفة معينة. على سبيل المثال ، يوجد في مطاعم البيتزا نواب مديرين يمكنهم قيادة مشاريع معينة: وضع الجداول الزمنية أو مراعاة المواد الخام. لكن ليس لدينا إصدار حقوق لمكونات محددة للنظام. يجب عليك منح حق الوصول الكامل إلى الخدمة حتى يتمكن الموظفون من الوصول إلى الجدولة أو الإعدادات الخاصة بأي مكون محاسبة.
دفعتنا المشكلات إلى تصميم نسخة جديدة من Auth وكتابتها. في بداية المشروع ، قضينا 3 أسابيع فقط في دراسة معايير التفويض والمصادقة OAuth 2.0 و OpenID Connect 1.0.
ملحوظة... المقالة مبالغ فيها ، هي إعادة سرد لـ RFC ، والتي كان لا بد من إعادة قراءتها عدة مرات لفهم ما كان يحدث حولها. حاولت هنا الابتعاد عن هذا التعقيد وإخبار كل شيء ببساطة ومنظم ودقيق وبدون وصف الأشياء المعقدة ، على سبيل المثال ، ما هي الشخصيات التي قد تحتويها استجابة الخدمة. على عكس RFC ، بعد قراءة هذا مرة واحدة ، يمكنك معرفة كل شيء. آمل أن تكون المقالة مفيدة وتوفر الوقت عند اختيار حل لتنفيذ خدمة المصادقة ، أو ربما تجعل شخصًا ما يفكر في حاجتها.
ما هو OAuth2.0؟
قررنا البدء في تطوير Auth الجديد من خلال فحص البروتوكولات والتقنيات المتاحة. معيار التفويض الأكثر شيوعًا هو إطار عمل تفويض OAuth2.0.
تم اعتماد المعيار في عام 2012 ، وعلى مدار 8 سنوات تم تغيير البروتوكول واستكماله. هناك العديد من طلبات التعليقات (RFC) لدرجة أن مؤلفي البروتوكول الأصلي قرروا كتابة OAuth 2.1 ، والذي سيجمع كل التغييرات الحالية على OAuth 2.0 في مستند واحد. بينما هو في مرحلة المسودة .
الإصدار الحالي من OAuth موصوف في RFC 6749 . سنقوم بتحليلها.
OAuth 2.0 هو إطار عمل تفويض.
يصف كيفية تنفيذ الاتصال بين الخدمات لضمان الحصول على إذن آمن. يتم وصف العديد من الفروق الدقيقة بتفاصيل كافية ، على سبيل المثال ، تدفق تفاعل العقد مع بعضها البعض ، لكن بعضها يترك تحت رحمة تنفيذ معين.
ميزات:
- فصل كيان المستخدم والتطبيق طالب الوصول . بفضل هذا الفصل ، يمكننا إدارة حقوق التطبيق بشكل منفصل عن حقوق المستخدم.
- بدلاً من تسجيل الدخول وكلمة المرور المعتادين ، اللذين لهما مجموعة معينة من الحقوق ومدى الحياة ، يمكننا الوصول إلى الموارد باستخدام سلاسل تم إنشاؤها عشوائيًا - الرموز المميزة .
- يمكنك إصدار الحقوق بأكبر قدر ممكن من الدقة ، بناءً على رغباتك الخاصة ، وليس بناءً على مجموعة حقوق محددة مسبقًا.
دعنا نلقي نظرة فاحصة على الميزات.
الأدوار
يحدد OAuth 2.0 أربعة أدوار:
- مالك المورد هو كيان لديه حقوق الوصول إلى مورد محمي. يمكن أن يكون الكيان مستخدمًا نهائيًا أو نوعًا من النظام. المورد المحمي هو نقطة نهاية HTTP ، والتي يمكن أن تكون أي شيء: نقطة نهاية API ، ملف على CDN ، خدمة ويب.
- خادم الموارد - خادم يخزن موردًا محميًا يمكن لمالك المورد الوصول إليه.
- العميل . هذا تطبيق يطلب الوصول إلى مورد محمي نيابة عن مالك المورد وبإذن منه - بإذن.
- خادم التفويض - خادم يصدر رمزًا مميزًا للعميل للوصول إلى مورد محمي بعد تفويض ناجح لمالك المورد.
يمكن لكل مشارك في التفاعل الجمع بين عدة أدوار. على سبيل المثال ، يمكن للعميل أن يكون مالكًا للمورد في نفس الوقت ويطلب الوصول إلى موارده الخاصة. سننظر في مخطط التفاعل بشكل أكبر.
هام: يجب أن يكون العميل مسجلاً في الخدمة مقدمًا. كيف افعلها؟
تسجيل العميل
يمكنك اختيار طريقة تسجيل العميل ، على سبيل المثال ، الاكتشاف اليدوي أو اكتشاف الخدمة ، اعتمادًا على
عنوان URI لإعادة التوجيه - العنوان الذي سيتم إرسال مالك المورد إليه بعد التفويض الناجح. بالإضافة إلى التفويض ، يتم استخدام العنوان لتأكيد أن الخدمة التي تقدمت بطلب للحصول على إذن هي من تدعي أنها.
نوع العميل - نوع العميل الذي يحدد كيفية تفاعلك معه. يتم تحديد نوع العميل من خلال قدرته على تخزين بيانات اعتماده بشكل آمن للحصول على إذن - رمز مميز. لذلك ، هناك نوعان فقط من العملاء:
- Confidential — , . , web-, backend.
- Public — . , , .
الرمز المميز في OAuth 2.0 عبارة عن سلسلة غير شفافة للعميل. عادةً ما تبدو السلسلة وكأنها تم إنشاؤها عشوائيًا - لا يهم تنسيقها للعميل. الرمز المميز هو مفتاح للوصول إلى شيء ما ، على سبيل المثال ، إلى مورد محمي (رمز وصول) أو إلى رمز جديد (رمز تحديث).
كل رمز له عمر خاص به . ولكن يجب أن يحتوي رمز التحديث على المزيد ، لأن يتم استخدامه للحصول على رمز وصول. على سبيل المثال ، إذا كان عمر رمز الوصول حوالي ساعة ، فيمكن ترك رمز التحديث للعيش لمدة أسبوع كامل.
رمز التحديث اختياري ومتاح فقط للعملاء الكونفدراليين... باستخدام الرمز المميز الاختياري ، في بعض التطبيقات ، يكون عمر رمز الوصول طويلاً جدًا ، ولا يتم استخدام رمز التحديث على الإطلاق ، حتى لا تتعب نفسك بالتحديث. لكن هذا ليس آمنًا. إذا تم اختراق رمز الوصول ، فيمكن إعادة تعيينه وستتلقى الخدمة رمز وصول جديد باستخدام رمز التحديث. إذا لم يكن هناك رمز تحديث ، فستحتاج إلى متابعة عملية التفويض مرة أخرى.
يتم تعيين رمز وصول لمجموعة معينة من حقوق الوصول ، والتي يتم إصدارها للعميل أثناء التفويض. لنلقِ نظرة على شكل الأذونات في OAuth 2.0.
حقوق الوصول
يتم إصدار حقوق الوصول للعميل كنطاق. النطاق عبارة عن معلمة تتكون من سلاسل مفصولة بمسافة - رمز النطاق.
يمثل كل نطاق من الرموز المميزة حقوقًا محددة ممنوحة للعميل. على سبيل المثال ،
doc_read يمكن أن يوفر النطاق المميز وصولاً للقراءة إلى مستند موجود على خادم الموارد ، employee والوصول إلى وظائف التطبيق فقط لموظفي الشركة. قد يبدو النطاق النهائي كما يلي email doc_read employee:.
في OAuth 2.0 ، ننشئ الرموز المميزة للنطاق بأنفسنا ، ونخصصها لتناسب احتياجاتنا. تقتصر أسماء رموز النطاق على الخيال وشخصيتين ASCII -
"و \.
في مرحلة تسجيل العميل ، في إعدادات خدمة التفويض ، يتم منح العميل نطاقًا قياسيًا بشكل افتراضي. ولكن يمكن للعميل أن يطلب من خادم التفويض نطاقًا غير النطاق القياسي. اعتمادًا على السياسات الموجودة على خادم التفويض واختيار مالك المورد ، قد يبدو النطاق الناتج مختلفًا تمامًا. في المستقبل ، بعد تفويض العميل ، يمكن لمالك المورد أن يأخذ بعض الحقوق دون إعادة تفويض الخدمة ، ولكن من أجل إصدار أذونات إضافية ، ستكون هناك حاجة إلى إعادة تفويض العميل.
OAuth الملخص 2.0. التدفق باستخدام رمز الوصول
نظرنا إلى الأدوار ، وبحثنا في أنواع الرموز ، والشكل الذي يبدو عليه النطاق. دعونا نلقي نظرة على تدفق توفير الوصول إلى الخدمة.
يوجد أدناه مخطط تجريدي (أو تدفق) للتفاعل بين المشاركين. يتم تنفيذ جميع الخطوات في هذا الرسم البياني بدقة من أعلى إلى أسفل. دعنا نحلل بمزيد من التفصيل.
- يرسل العميل طلبًا للوصول إلى مالك المورد المطلوب.
- يعيد مالك المورد للعميل منحة التفويض ، والتي تؤكد هوية مالك المورد وحقوقه في المورد الذي يطلب العميل الوصول إليه. اعتمادًا على التدفق ، يمكن أن يكون هذا رمزًا مميزًا أو بيانات اعتماد.
- يرسل العميل منح التفويض الذي تم الحصول عليه في الخطوة السابقة إلى خادم التفويض ، ويتوقع وجود رمز وصول منه للوصول إلى المورد المحمي.
- يتأكد خادم التفويض من صلاحية منح التفويض ، ثم يرسل رمز الوصول مرة أخرى إلى العميل.
- بعد تلقي رمز الوصول ، يطلب العميل المورد المحمي من خادم المورد.
- يتأكد خادم المورد من صحة رمز الوصول ثم يوفر الوصول إلى المورد المحمي.
يتلقى العميل موافقة من مالك المورد ، على أساس منحه حق الوصول إلى المورد. انه سهل. هل سيكون الأمر سهلاً إذا أضفنا رمز التحديث إلى هذا المخطط؟
OAuth الملخص 2.0. التدفق باستخدام رمز التحديث
تم حذف الخطوتين الأولى والثانية من هذا الرسم التخطيطي - فهي لا تختلف عن مخطط التدفق المجرد أعلاه.
المخطط بمزيد من التفصيل:
- يأتي العميل مع منح تفويض لخادم التفويض ويطلب تزويده برمز الوصول وتجديد الرمز المميز.
- Authorization server , authorization grant access token refresh token.
- Client access token , — invalid token error.
- , authorization server refresh token access token .
- access token, refresh token, refresh token.
grant?
المنحة هي البيانات التي تمثل التفويض الناجح للعميل من قبل مالك المورد ، ويستخدمها العميل للحصول على رمز وصول.
على سبيل المثال ، عندما نقوم بالمصادقة مع Google في مكان ما ، ينبثق إشعار أمام أعيننا. تقول أن كذا وكذا خدمة تريد الوصول إلى بيانات عنك أو إلى مواردك (يتم عرض رمز النطاق المطلوب). يسمى هذا الإشعار "شاشة الموافقة".
في اللحظة التي نضغط فيها على "موافق" ، تدخل المنحة نفسها إلى قاعدة البيانات: يتم تسجيل البيانات التي منحها هذا المستخدم كذا وكذا الوصول إلى خدمة كذا وكذا. يتلقى العميل نوعًا من معرف المصادقة الناجح ، مثل سلسلة مرتبطة بالبيانات الموجودة في قاعدة البيانات.
هناك طرق 4 + 1 للحصول على منحة - نوع المنحة:
- Authorization code — confedencial — web-.
- Client credentials — confedential , , .
- Implicit — public-, redirection URI (, ), authorization code grant PKCE (Proof Key for Code Exchange — , , token , . — RFC 7636).
- بيانات اعتماد كلمة مرور مالك المورد . في أمان OAuth 2.0 RFC 6819 ، يعتبر هذا النوع من المنح غير موثوق به. إذا كان مسموحًا في وقت سابق باستخدامه فقط لترحيل الخدمات إلى OAuth 2.0 ، فلا يُسمح في الوقت الحالي باستخدامه على الإطلاق.
- ترخيص الجهاز (مضاف في RFC 8628) - يستخدم لترخيص الأجهزة التي قد لا تحتوي على مستعرضات ويب ، ولكن يمكنها العمل عبر الإنترنت. على سبيل المثال ، هذه هي تطبيقات وحدة التحكم أو الأجهزة الذكية أو أجهزة التلفزيون الذكية.
الوحيد رمز التفويض (مع PKCE)، أوراق اعتماد العميل و جهاز منحة إذن يمكن اعتبار ذات الصلة ، ولكن سننظر في كل شيء. سننظر في المنح من أجل زيادة تعقيد الفهم.
Client credentials grant flow
إنه يتمتع بأبسط تدفق ، يذكرنا بالتفويض المنتظم في أي خدمة. يتم إجراؤها باستخدام بيانات اعتماد العميل ، وهي معرف العميل وسر العميل - تناظرية لتسجيل الدخول وكلمة المرور للمستخدم. نظرًا لأن المصادقة تتطلب سرًا للعميل يجب تخزينه بشكل مناسب ، فلا يمكن استخدام هذا التدفق إلا من قبل العملاء الكونفدراليين.
النظام بسيط: تتم مصادقة العميل على خادم التفويض عن طريق تمرير معرف العميل وسر العميل. رداً على ذلك ، يتلقى رمز وصول ، يمكنه بالفعل الوصول إلى الخدمة المطلوبة.
هذا التدفق مطلوب عندما يحاول العميل الوصول إلى موارده أو موارده المتفق عليها مسبقًا مع خادم التفويض. على سبيل المثال ، تحتاج الخدمة "أ" إلى الانتقال إلى الخدمة "ب" من وقت لآخر وتحديث البيانات هناك حول عدد مطاعم البيتزا في الشبكة.
تدفق بيانات اعتماد كلمة مرور مالك المورد
وفقًا لتوصيات الأمان الحالية الموضحة في RFC هذا ، لا يوصى باستخدام هذا التدفق على الإطلاق بسبب مخاوف أمنية واضحة.
في الرسم التوضيحي لهذا التدفق ، هناك عميلان ، ومن الناحية النظرية يجب أن يكون هناك عميل وخادم تفويض.
ينقل مالك المورد اسم المستخدم وكلمة المرور الخاصة به إلى العميل ، على سبيل المثال ، من خلال النماذج الخاصة بالعميل. العميل ، بدوره ، يستخدمه للحصول على رمز وصول (واختياريًا ، رمز تحديث).
هناك مشكلة هنا. يأخذ مالك المورد ببساطة اسم المستخدم وكلمة المرور الخاصين به ويعطيها بشكل واضح للعميل ، وهو أمر غير آمن. تم إنشاؤه في الأصل فقط للعملاء الذين تثق بهم أو أولئك الذين يشكلون جزءًا من نظام التشغيل. في وقت لاحق ، تم السماح له فقط بالترحيل من مصادقة تسجيل الدخول وكلمة المرور إلى OAuth 2.0. تحظر إرشادات الأمان الحالية استخدامه.
قانون التفويض
التدفق الأكثر شيوعًا في الوقت الحالي. تستخدم في الغالب للعملاء السريين ، ولكن مع إدخال التحقق الإضافي مع PKCE ، يمكن استخدامها أيضًا للعملاء العامين.
في هذا التدفق ، يمر التفاعل بين العميل ومالك المورد عبر وكيل المستخدم (المتصفح). وكيل المستخدم له مطلب واحد: يجب أن يكون قادرًا على العمل مع عمليات إعادة توجيه HTTP. بدون ذلك ، لن يتمكن مالك المورد من الوصول إلى خادم التفويض والعودة مرة أخرى بمنحة.
هذا التدفق أكثر تعقيدًا من السابق ، لذلك سنقوم بتحليله خطوة بخطوة. بادئ ذي بدء ، دعنا نتخيل أننا مالك مورد وانتقلنا إلى صفحة خدمة التعلم عبر الإنترنت التي تريد حفظ نتائج التعلم في السحابة الخاصة بنا. يحتاج للوصول إلى مواردنا ، على سبيل المثال ، دليل معين في السحابة. نضغط على "تسجيل الدخول" وتبدأ الرحلة عبر تدفق منح رمز التفويض:
- في الخطوة الأولى ، يعيد العميل توجيه مالك المورد باستخدام وكيل المستخدم إلى صفحة مصادقة خادم التفويض. في URI ، تحدد معرف العميل وإعادة التوجيه URI. يتم استخدام عنوان URI لإعادة التوجيه لفهم مكان إرجاع مالك المورد بعد نجاح التفويض (سوف يمنح مالك المورد الإذن للنطاق الذي طلبه العميل).
- user-agent, resource owner .
- Resource owner , consent screen .
- Resource owner user-agent URI, redirection URI. query- authorization code — , , resource owner .
- authorization code , access token ( refresh token, ).
- authorization code, , access token ( refresh token). .
إذا تخيلنا مكان مالك المورد ، فإننا نرى فقط إعادة توجيه إلى خادم التفويض ، والمصادقة ، وتأكيد الوصول إلى شاشة الموافقة وإرسالنا إلى خدمة قيد التشغيل بالفعل. على سبيل المثال ، نمر بهذا عدة مرات عندما نذهب إلى الخدمة بحساب Google أو Facebook أو Apple.
يعتمد التدفق التالي على هذا.
منحة ضمنية
هذا تحسين لتدفق منح كود التفويض للعملاء العموميين الذين يعرفون كيفية العمل مع عناوين URI لإعادة التوجيه. على سبيل المثال ، لتطبيقات متصفح JavaScript أو تطبيقات الهاتف المحمول. تظل متطلبات وكيل المستخدم ، والتي من خلالها يتفاعل العميل ومالك المورد: يجب أن يكون قادرًا على العمل مع عمليات إعادة توجيه HTTP.
هناك فرق رئيسي بين رمز التفويض والضمني: فبدلاً من تلقي رمز التفويض ورمز الوصول عليه ، نتلقى فورًا رمز الوصول بعد التفويض الناجح لمالك المورد. بالإضافة إلى ذلك ، لا يتم استخدام سر العميل هنا لأسباب أمنية - يمكن تفكيك التطبيق واسترجاعه. يتم التحقق من الأصالة فقط عن طريق إعادة التوجيه URI.
تتشابه العديد من الخطوات من هذا الرسم البياني مع الخطوات الواردة في كود التفويض ، لكنني أقترح تحليلها بالتفصيل أيضًا. لنتخيل أن أحد تطبيقات المستعرض يريد حفظ إعداداته في مستودع Git الخاص بنا. نضغط على "تسجيل الدخول إلى GitHub" وفي هذه المرحلة يبدأ التدفق الضمني:
- يستخدم العميل وكيل المستخدم وإعادة توجيه HTTP لإعادة توجيه مالك المورد إلى خادم التفويض. في معلمات الطلب ، يقوم بتمرير معرف العميل وإعادة التوجيه URIs اللازمة لمصادقة العميل ثم إعادة مالك المورد مرة أخرى.
- تتم مصادقة مالك المورد من خلال الاتصال عبر وكيل المستخدم بخادم التفويض. في الوقت نفسه ، تؤكد على إصدار منحة للعميل الذي جاء بهوية العميل.
- grant ( «allow» consent screen), user-agent resource owner redirection URI. , URI fragment access token (URI fragment — , URI ‘#’).
- user-agent. User-agent redirection URI web-, access token . , , , CDN.
- Web- web- ( ), redirection URI, , .
- User-agent , , web-hosted client resource, access token.
- وكيل مستخدم رمز الوصول الناتج ينتقل ببساطة إلى العميل.
هذا تدفق معقد. ليس لها فائدة تذكر في سيناريوهات العالم الحقيقي. ولكن لا يزال من الممكن العثور عليها في المشاريع القديمة.
ترخيص الجهاز (RFC 8628)
من عام 2012 إلى عام 2019 ، ظهرت العديد من الأجهزة الذكية غير الملائمة لتسجيل الدخول. على سبيل المثال ، من غير الملائم إدخال اسم مستخدم وكلمة مرور معقدة على التلفزيون في كل مرة تفتح فيها موردًا. هذا غير ممكن في بعض الأجهزة ، مثل أنظمة تشغيل الخادم بدون واجهة رسومية. في أغسطس 2019 ، ظهر هذا التدفق لمثل هذه السيناريوهات فقط.
هناك ما لا يقل عن 3 متطلبات للأجهزة للعمل مع تدفق منح ترخيص الجهاز ليكون ممكنًا:
- يجب أن يكون الجهاز قادرًا على إجراء طلبات HTTPS الصادرة.
- يجب أن يكون الجهاز قادرًا على عرض URI والمعرف للمستخدم.
- ينتمي كل جهاز معتمد إلى مالك المورد ، الذي ، للحصول على إذن ناجح ، يجب أن يكون لديه جهاز آخر مع متصفح للانتقال إلى URI المحدد وإدخال الرمز المحدد.
ربما يبدو المخطط معقدًا بسبب وفرة الأسهم. دعنا نحللها خطوة بخطوة ، حيث قمنا بتحليل التدفقات المعقدة قبلها.
لنفترض أننا نحاول تسجيل الدخول إلى خدمة ويب باستخدام التلفزيون. نرى زر "تسجيل الدخول كجهاز" وانقر. في هذه اللحظة ، يبدأ تدفق أجهزتنا:
- يقدم التلفزيون طلبًا إلى خادم التفويض ، ويمنحه معرف العميل الخاص به.
- يتحقق خادم التفويض من أن هذا العميل مسجل ولديه نوع المنحة المناسب.
- , Authorization server device code, user code verification URI. Device code — , .
- user code verification URI — resource owner. Redirection URI , QR- — .
- , user code verification URI, .
- resource owner. verification URI, user code, , scope . resource owner .
- طوال هذا الوقت ، قام الجهاز (النقطة 3) باستطلاع رأي خادم التفويض حول نجاحه. ينتقل الجهاز مرة أخرى إلى خادم التفويض برمز الجهاز ومعرف العميل على أمل أن يكون التفويض قد اجتاز هذه المرة.
- هذه المرة ، عندما أكد مالك المورد نقل الحقوق الضرورية إلى الجهاز ، يقوم خادم التفويض بإرجاع رمز وصول استجابة للطلب (إذا تم توفيره بواسطة إعدادات الخادم ورمز التحديث). وبمساعدة الرمز المميز ، يمكن للجهاز بالفعل متابعة العمل مع المورد.
على الرغم من التعقيد الظاهر مع الأسهم ، فإن هذا التدفق بسيط للغاية أيضًا. إذا كنت بحاجة إلى التفاعل مع الأجهزة (ولدينا الكثير منها: متعقب ، وسجل نقدي ، وواجهات متاجر وأجهزة أخرى) ، فعليك استخدام هذا التدفق.
بدلا من الإخراج
في هذا المقال ، حذفت الكثير من التفاصيل من أجل التحدث عن أهم الأشياء بأبسط الطرق وأكثرها سهولة. على سبيل المثال ، أنواع الطلبات ، وكيف وفي أي شكل لتمرير المعلمات ، ما هي الأحرف المسموح بها كقيم لذلك.
إذا كنت ترغب في التعمق في الموضوع بمزيد من التفصيل ، فأنا أوصي باستخدام RFC 6749 (لـ OAuth 2.0) و RFC 8628 (لتدفق الجهاز). يمكنك أيضًا التحقق من مورد OAuth للحصول على طلبات RFC محدثة .
إذا كانت المقالة مفيدة وتريد مزيدًا من التفاصيل - اكتب في التعليقات ، وفي المقالات التالية سأتحدث عن PKCE وبروتوكول مصادقة OpenID Connect 1.0 وتطبيقنا لخادم المصادقة وغير ذلك الكثير.
روابط مفيدة: