أنا متأكد أن لديك حساب واحد أو أكثر على وسائل التواصل الاجتماعي.
سواء كان الفيسبوك، تويتر، يوتيوب، جوجل، جيثب،
أو العديد من مقدمي الخدمات الآخرين، حيث قمت بتسجيل الهاتف والحساب.
الآن، مقدمي الخدمات هؤلاء
بدورهم، على استعداد لتقديم خدمات المصادقة نيابة عنك.
لذلك، على سبيل المثال، ترى انتشار عدد من مواقع الويب
وتطبيقات الجوال حيث يسمح لك بتسجيل الدخول
باستخدام حسابات وسائل التواصل الاجتماعي الخاصة بك.
الآن، كيف يعمل هذا في الواقع؟
يعمل العديد من موفري حسابات وسائل التواصل الاجتماعي هؤلاء
كموفري خدمة مصادقة باستخدام بروتوكول يسمى OAuth.
سنلقي نظرة على OAuth وكيفية تمكين موفري المصادقة التابعين
لجهات خارجية هؤلاء من تقديم المصادقة نيابة عنك،
والسماح لك بتسجيل الدخول إلى خدمات أخرى باستخدام حسابات وسائل التواصل الاجتماعي الخاصة بهم.
أنا متأكد من أنك قد سمعت في تمرير OAuth 1 و OAuth 2،
وربما سمعت من أشخاص يقولون
أن Facebook يوفر مصادقة تستند إلى OAuth 2،
أو توفر Google مصادقة تستند إلى OAuth 2 وما إلى ذلك.
أنا متأكد من أنك يجب أن تتساءل،
ما هي بالضبط هذه OAuth1 و OAuth 2 المقصود أن تكون؟
الآن، OAuth1 و OAuth 2
هما أطر تفويض تستند إلى معايير مفتوحة.
ويمكن استخدامها عبر الإنترنت لمصادقة
هويتك للعديد من مواقع الويب أو تطبيقات الجوال.
الآن، عند استخدامك لهذه الخدمات،
فإنك تعتمد على أحد حسابات وسائل التواصل الاجتماعي مثل فيسبوك،
وجوجل، وتويتر، ومايكروسوفت، وإنستغرام
، وجيثب، وديجيتالوسين، وغيرها الكثير،
الذين يقدمون خدمات المصادقة هذه للآخرين للاستفادة منها.
يعد
موفرو خدمة المصادقة هؤلاء لمستخدمي خدمة المصادقة هذه بأنهم سيصادقون هوية
المستخدم بناءً على تقديمهم
لبيانات اعتمادهم لخدمات وسائل التواصل الاجتماعي هذه.
الآن، هناك خدمة تكميلية أوبينيد.
ولكن، بالطبع، لا علاقة لـ OAuth ولكن يوفر نوعًا مشابهًا من الخدمة.
ولكن معظم موفري خدمات وسائل التواصل الاجتماعي القياسيين،
كما سترون مذكورين هنا،
يقدمون خدمات تستند إلى OAuth 2 هذه الأيام.
الآن، كما ذكرت، فإن OAuth1 و OAuth 2 هما بروتوكولات مصادقة،
وكان OAuth 1 البروتوكول الأول الذي دخل حيز الوجود.
وقد تطور هذا من تويتر،
بلين كوك
هو الشخص وراء ذلك، وهذا موثق في فرقة العمل هندسة الإنترنت، RFC 5849.
لذا، إذا كنت تريد قراءة التفاصيل الدموية لكيفية عمل هذه البروتوكولات،
فهذا هو المكان المناسب للعثور على ذلك.
تطور بروتوكول OAuth 2 من OAuth 1 لجعله أكثر بساطة،
ولتوفير طريقة أبسط لتطوير العميل.
وهذا موثق في IETF RFC 6749 وبعد ذلك،
جاء استخدام رمزية حامل آخر في IETF RFC 6750.
الآن، من وجهة نظرنا،
نحن لا نريد حقا الخوض في تفاصيل كيفية عمل هذه البروتوكولات في الواقع.
بدلا من ذلك، كل ما يهمنا في ذلك هو،
كيف يمكننا الاستفادة من هذه لمصادقة المستخدم داخل تطبيق الويب الخاص بنا،
أو داخل تطبيقنا للهاتف المحمول،
عندما نحتاج إلى مصادقة المستخدم
على خادم Express الذي كنا نبني عليه حتى الآن؟
الآن، سنركز في المقام الأول على OAuth 2،
لأنه في التمرين،
سننظر في استخدام Facebook كمزود خدمة مصادقة OAuth 2
، وهنا، نحتاج إلى فهم
بعض المصطلحات لمعرفة كيفية عمل بروتوكول OAuth 2 بالضبط.
على الأقل، تفاصيل العظم العاري لكيفية عمل البروتوكول نفسه.
الآن، في حالة OAuth 2،
نتحدث دائمًا عن ملكية المورد.
الآن في هذه الحالة،
المورد الذي أشير إليه ليس
المورد الذي يتم تخزينه على خادم Express.
بدلاً من ذلك، المورد الذي نشير إليه هنا،
هو هوية المستخدم.
الآن، أي خادم، مثل خادم Express الذي كنا نبني،
يريد الوصول إلى هذا المورد،
وهذا هو هويتك.
الآن، أين هويتك؟
يتم تخزين هويتك على أحد
مزودي خدمات مصادقة وسائل التواصل الاجتماعي مثل Facebook وما إلى ذلك،
لأنك قمت بالفعل بإنشاء حساب على مواقع التواصل الاجتماعي هذه.
لذلك،
يتم تخزين معلوماتك أو معلومات هويتك أو معلومات ملفك الشخصي في Facebook، على سبيل المثال.
الآن، يريد خادم Express الوصول إلى هويتك
والتحقق من أنك تحاول الوصول إلى خادم Express.
لذلك، في هذه الحالة، يعمل
خادم Express الذي قمنا بتطويره،
بمثابة تطبيق العميل.
لذلك، هذا هو المكان الذي تطبيق العميل،
وهو موقع الويب أو التطبيق المحمول الذي يريد
الوصول إلى خادم الموارد من أجل الحصول على المعلومات عنك.
ما هو خادم الموارد الذي نتحدث عنه؟
هذا هو خادم مصادقة Facebook OAuth،
والذي يوفر أيضًا معلومات ملفك الشخصي عند الطلب.
الآن، بالطبع، لن تستمر في توزيع معلومات ملفك الشخصي بشكل عشوائي.
بدلاً من ذلك، تريد أن تكون قادراً على التحقق من توفير الوصول إلى
معلومات ملف التعريف الخاص بك إلى موفر خدمة مصادق عليه أو ملقم مصادق عليه.
الآن، هذا هو المكان الذي
يقوم فيه تطبيق العميل الخاص بك أو خادم Express هنا، على سبيل المثال، بالتسجيل في Facebook بحساب يقول
أنني أقوم بتشغيل تطبيق، وأريد تسجيل نفسي كمصدر محتمل يمكنه
الاقتراب منك لمصادقة المستخدمين عندما يوفرون
الوصول إلى ملفك الشخصي الذي يتم تخزينه على موقع الويب الخاص بك.
لذلك، فإن خادم إكسبريس،
في هذه الحالة بمثابة تطبيق العميل،
سيتم تسجيل نفسه على الفيسبوك والحصول على كلينتيد وسر العميل من الفيسبوك.
الآن، عندما يسجل خادم Express على Facebook،
يجب أن يكون لديك حساب على Facebook،
وهو حساب مصدق على Facebook،
والذي ستستخدمه لإعداد هذا التطبيق على Facebook.
لذلك، بمجرد تسجيل نفسك،
ثم سوف تحصل على الوصول إلى كلينتيد وسر العميل.
الآن، خادم المورد،
كما ذكرت، هو الخادم الذي يستضيف البيانات المحمية.
بيانات محمية تعني ملف تعريف المستخدم الذي يريد الوصول إلى خادم Express.
لذلك، يريد خادم Express الوصول إلى خادم المورد هذا،
والحصول على بيانات ملف التعريف للمستخدم الذي يريد الوصول إلى خادم Express.
لذا، تَرى العلاقةَ هنا.
لذلك، عندما أتحدث عن تطبيق عميل،
لا أقصد تطبيقهم الأمامي،
ولكن خادم Express الخاص بهم يحاول توفير
الوصول إلى الموارد التي لديها على موقعه.
لكن خادم Express،
من أجل تمكينك من الوصول،
سيحتاج إلى الوصول إلى خادم موارد Facebook الخاص بك والذي
سيصادق عليك ويقدم معلومات ملفك الشخصي إلى خادم Express.
لذا، فإن خادم الموارد الذي أتحدث عنه هنا،
هو خادم مصادقة OAuth 2 في Facebook
بالإضافة إلى خادم الموارد الذي يمنحك الوصول إلى معلومات الملف الشخصي للمستخدم.
وخادم التفويض هو الخادم الذي
سيأذن لشخص ما بالوصول
إلى خادم المورد من أجل استرداد معلومات ملف التعريف.
الآن، المستخدم هو الذي يحتوي على معلومات ملف التعريف على خادم المورد.
يجب على المستخدم تخويل ملقم Express للانتقال
إلى ملقم المورد هذا لجلب معلومات ملف التعريف.
ولكن إذا كان المستخدم يحتاج إلى تفويض خادم Express،
يحتاج المستخدم إلى تسجيل الدخول إلى حساب Facebook،
ومن ثم الحصول على معلومات من Facebook تسمى كرمز وصول،
والذي سيقوم المستخدم بعد ذلك بتمريره إلى خادم Express.
الآن، عندما يتم الحصول على رمز الوصول من Facebook من خلال بروتوكول OAuth 2،
سيتم إصدار رمز الوصول
من حيث السماح لهذا التطبيق العميل أو خادم Express،
الذي تم تسجيله بالفعل في Facebook قائلا إن
خادم العميل هذا سوف يأذن
بالوصول إلى معلومات الملف الشخصي الخاصة بهم من موفر خدمة OAuth على Facebook.
لذا، مرة أخرى، هذا مربك بعض الشيء.
سنرى تخطيطًا حيث
يتم شرح تدفق المعلومات هذا بشكل أكثر وضوحًا لك.
نقطة واحدة ذكرتها للتو هي حول رمز OAuth أو الرمز المميز للوصول.
ما هو رمز الوصول هذا؟
رمز الوصول هو شيء يصدقه خادم التفويض بالنسبة لك.
أي خادم تخويل؟
هذا هو خادم تخويل OAuth 2 الطرف الثالث،
خادم Facebook، في هذا المثال.
لذلك هم تطبيق خادم Express.
الآن، أنت، كمستخدم أمامي،
تريد الوصول إلى شيء من تطبيق خادم Express.
سيخبرك تطبيق خادم Express أنك تقوم بمصادقة
نفسك من Facebook ثم تحصل على رمز وصول من Facebook.
يتم إصدار رمز الوصول هذا
للمستخدم الأمامي من Facebook عندما يقوم المستخدم بتسجيل الدخول إلى حساب Facebook الخاص به.
الآن يتم إصدار رمز الوصول هذا باسم تطبيق العميل،
خادم Express، الذي تم تسجيله بالفعل في Facebook.
لذلك، لكي يتمكن المستخدم من الوصول إلى Facebook للحصول على رمز الوصول الخاص به،
يتطلب المستخدم معرف العميل الخاص بتطبيق العميل أو تطبيق Express.
لذلك يتم تضمين معرف العميل هذا
في تطبيق الواجهة الأمامية أن هذا الخادم إكسبريس سوف تخدم لك.
لذا فإن خادم Express يقدم موقعًا إلكترونيًا تقوم بالوصول إليه،
فسيحتوي هذا الموقع على رمز حيث يكون
معرف العميل الخاص بخادم Express مضمنًا بالفعل هناك.
قطعة أخرى من المعلومات التي ذكرتها هي سر العميل.
الآن، في تدفق المصادقة الذي سأتحدث عنه،
لن يتم الكشف عن سر العميل لأي شخص.
سيكون سر العميل فقط على جانب الخادم Express.
مرة أخرى عندما يحاول خادم Express المصادقة
والحصول على الوصول إلى ملف تعريف المستخدم من Facebook،
وتطبيق العميل، سيقوم خادم Express
بإرسال كل من معرف العميل وسر العميل،
جنبا إلى جنب مع رمز الوصول الذي يقدمه المستخدم إليه إلى Facebook.
و الفيسبوك، بدوره،
يأذن تطبيق العميل الخاص بهم للوصول
إلى خادم الموارد من أجل الحصول على بيانات الملف الشخصي للمستخدم.
وبمجرد الحصول على بيانات ملف تعريف المستخدم من خادم موارد Facebook،
سيقوم خادم Express الخاص بي بإنشاء حساب
لهذا المستخدم المحدد الذي قام بتسجيله باستخدام حساب Facebook الخاص به.
وبعد ذلك، قم بتزويد رمز ويب JSON للمستخدم،
والذي يمكن للمستخدم استخدامه بعد ذلك للوصول إلى
الموارد المخزنة على خادم Express.
لذلك، مرة أخرى، لتلخيص هذا،
لدي رسم تخطيطي هنا لشرح هذا لك بمزيد من التفصيل.
بالإضافة إلى ذلك،
هناك أيضا رمز تحديث.
عندما يتم إصدار رمز وصول من قبل خادم Facebook OAuth 2،
يكون رمز الوصول الخاص به عمر محدود.
بعد ذلك، سيصبح رمز الوصول غير صالح.
لذلك يجب أن يبقى رمز الوصول سريًا.
لذلك
سيتم كل هذا التبادل من الرموز بين المواقع المختلفة في مسألة مشفرة باستخدام بروتوكول هتبس.
لذا تأكد من أنه عند إرسال رمز الوصول الخاص
بك من تطبيق الواجهة الأمامية للمستخدم إلى خادم Express،
سترسل رمز الوصول فقط عبر HTTPS، وليس HTTP.
هذا مهم جدًا لأنك لا
تريد أن يتم الكشف عن رمز الوصول الخاص بك لأي شخص لأن أي
شخص يمكنه الحصول على أحد رمز الوصول الخاص بك يمكنه التظاهر بأنه
تطبيق العميل الخاص به ثم الوصول إلى ملف تعريف المستخدم الخاص بك.
لذلك هذا مهم جدا.
الآن، بما أن رمز الوصول له عمر محدود،
فهناك أيضًا رمز تحديث مماثل،
والذي يمكن استخدامه لتحديث رمز وصول منتهي الصلاحية.
الآن، في نوع التدفق الذي
سنستخدمه مع تطبيقنا في التمرين،
لن نتمكن من استخدام رمز التحديث.
في أي وقت يريد المستخدم تخويل
خادم Express للذهاب وجلب معلومات الملف الشخصي من Facebook،
سيتعين على المستخدم توفير
رمز وصول جديد يتم الحصول عليه من Facebook بشكل صريح.
الجزء الوحيد الذي ذكرته للتو باختصار،
لكنني لم أشرح،
هو كيف يقوم تطبيق العميل، وخادم Express،
والمقاييس، وكيف يسجل نفسه في مزود خدمة OAuth 2؟
الآن، هذا هو المكان الذي
يوفر فيه العديد من مزودي خدمة OAuth 2 طريقة لتسجيل تطبيق على موقعهم.
لذلك
سيقوم تطبيق العميل، خوادم Express في مثالنا، بتسجيل نفسه كتطبيق عميل على موفر خدمة OAuth.
لذا كما سترى في التمرين، فإن
الخطوة الأولى التي سنقوم بها هي تسجيل الدخول إلى Facebook باستخدام
حسابنا ثم إنشاء تطبيق على موقع Facebook.
عند القيام بذلك، سيصدر لك Facebook معرف تطبيق العميل وسر العميل.
ينطبق هذا الإجراء على العديد من موفري خدمة OAuth الآخرين لأن
هذا هو التدفق العام الذي يتحدث عنه بروتوكول OAuth 2.
لذا فإن معرف تطبيق العميل وسر العميل مفيدان بالنسبة لنا حتى نتمكن من
إثبات هويتنا
لخادم OAuth عندما نمر برمز وصول نحصل عليه من المستخدم.
الآن، هناك أيضًا عنوان URL لإعادة التوجيه الذي تحتاج إلى
تسجيله عند تسجيل تطبيق العميل،
وستراني أقوم بذلك في الخطوات التي أقوم بتسجيل
التطبيق على موقع Facebook.
الآن، لتلخيص تدفق المعلومات
الذي تحدثنا عنه بإيجاز في حالة سابقة،
اسمحوا لي أن أبدأ في هذه المرحلة.
النقطة الأولى التي يجب النظر إليها هي مالك المورد.
لذا فإن مالك المورد هنا هو المستخدم الذي
سيستخدم حسابه على وسائل التواصل الاجتماعي.
يحتوي Facebook، في هذا المثال، على المصادقة للمستخدم.
لذا فإن مالك المورد هو الذي يحتوي على ملف تعريف حول المورد.
وهذه المعلومات الشخصية لكل حساب الفيسبوك،
تم تخزينها على خادم الفيسبوك.
وهكذا يوفر خادم Facebook خادم الموارد هنا.
لذلك هذا هو مزود خدمة OAuth الذي تراه
على الجانب الأيمن من هذه الصورة هنا.
لذا تخيل خادم Facebook على الجانب الأيمن، تطبيق العميل هذا،
الذي يحتوي على خادم API الباقي،
خادم Express الذي قمنا بتنفيذه،
هو تطبيق عميل في هذه الحالة،
ومالك المورد هو المستخدم.
عنوان URL المستخدم الأمامي، الذي
سيسمح لك بالانتقال إلى Facebook للتحقق من بيانات اعتماد هذا المستخدم.
لذلك عندما تريد الوصول إلى المعلومات على جانب العميل،
سيكون لديك أولا للذهاب
وتخويل هذا التطبيق العميل لتكون قادرة على
الحصول على الوصول إلى معلومات ملف التعريف الخاص بك.
وبالتالي فإن تطبيق العميل،
إذا كان بمثابة التطبيق على شبكة الإنترنت،
فإنه سيوفر زر مناسب في هناك قائلا تسجيل الدخول باستخدام الفيسبوك.
وهكذا عند النقر على الزر، في
الأساس، يتم بدء الخطوة الأولى.
يتم بدء طلب تخويل المستخدم.
لذلك تطبيق العميل الخاص بك،
من خلال وكيل المستخدم،
وكيل المستخدم هو في الأساس تطبيق العميل، وتطبيق الواجهة الأمامية.
يمكن أن يكون التطبيق Angular الذي قمنا بتطويره أو تطبيق الجوال،
سواء كان أيوني أو ما إذا كان
تطبيق NativeScript الذي قمنا بتطويره في الدورات السابقة في
التخصص أو حتى تطبيق أصلي مثل تطبيق iOS أو تطبيق Android.
كل هذه بمثابة وكيل المستخدم.
لذا فإن وكيل المستخدم،
يستخدمون عملية طلب التفويض من خلال
وكيل المستخدم إلى خادم التفويض،
وهو خادم Facebook.
الآن، عندما يتم تمرير ذلك في،
ثم مالك المورد أو المستخدم،
الذي يحاول إعطاء حق الوصول إلى ملفه الشخصي لهذا التطبيق العميل،
سوف تضطر إلى تخويل الفيسبوك
لتكون قادرة على مشاركة هذه المعلومات مع تطبيق العميل.
في نهج منحة التدفق الضمني الذي نستخدمه في
مثالنا هنا وأيضًا في التمرين التالي،
فإن نهج منح التدفق الضمني هو
النهج الأنسب عند تنفيذ تطبيق ويب باستخدام
إطار عمل مثل Angular أو تطبيق الجوال المختلط
مع Ionic أو NativeScript أو حتى التطبيق الأصلي.
إن نهج منح التدفق الضمني هو طريقة أكثر بساطة
لتشغيل OAuth 2 لمثل هذا النوع من التطبيقات.
ثم ينقر مالك المورد على زر تسجيل الدخول،
ثم سيطالب خادم التفويض مالك المورد بالمعلومات قائلا:
«يريد تطبيق العميل هذا الوصول إلى معلومات ملف التعريف الخاص بك.
هل تصرح بذلك؟»
وهكذا سيتم ظهور هذا من قبل الفيسبوك،
وبعد ذلك سوف تنقر على زر هناك قائلا، «نعم،
أنا أذونات هذا التطبيق العميل للوصول نيابة عني.»
لذلك، في هذه النقطة،
سيقوم خادم التفويض على Facebook، خادم تخويل OAuth 2 على Facebook، بإنشاء رمز وصول.
لإنشاء رمز الوصول
هذا، سيتم الاستفادة من معرف العميل لتطبيق العميل هذا،
تطبيق خادم Express الذي نقوم بتسجيله.
لذلك يجب أن يكون معرف العميل جزءًا من وكيل المستخدم الذي يستخدمه هذا المستخدم.
لذلك سيتم تضمين معرف العميل هذا في التطبيق الزاوي،
أيوني أو التطبيق ناتيفسكريبت أو حتى دائرة الرقابة الداخلية أو التطبيق الروبوت.
لذلك سيتم استخدام معرف العميل من قبل
وكيل المستخدم لتحويل خادم التفويض قائلا،
«هذا التطبيق العميل يريد الوصول إلى ملفي الشخصي،
وأنا على استعداد لتخويل لك للسماح بالوصول إلى الملف الشخصي.»
لذلك، عند هذه النقطة،
سيقوم خادم التفويض بإرسال رمز وصول إلى وكيل المستخدم في هذه الحالة.
لذا، تذكر، يأتي رمز الوصول هذا إلى وكيل المستخدم،
وهو تطبيق الجوال أو تطبيقه Angular الذي يتم تنفيذه من قبلنا.
ثم سيأخذ وكيل المستخدم هذا الرمز المميز للوصول
ثم تمرير رمز الوصول هذا إلى تطبيق العميل هذا.
لذا فإن OAuth لتسجيل الدخول،
ولكن سيتم تمرير رمز الوصول إلى تطبيق العميل،
خادم Express في هذه الحالة،
في مسار معين على جهاز التوجيه الخاص بالمستخدم،
مسار المصادقة على موقع تطبيق العميل.
الآن، في السابق، رأينا استخدام المصادقة المحلية،
حيث أرسلنا طلبًا لشرطة مائلة سجل دخول المستخدم.
الآن، لهذا للعمل في تطبيقنا،
سنقوم بإعداد واحد آخر على مستخدمي شرطة مائلة، شرطة
مائلة Facebook، رمز مائل، وما إلى ذلك.
لذلك عنوان URL آخر نقدم عليه رمز الوصول هذا إلى خادم Express.
الآن، عندما يتم الحصول على رمز الوصول هذا بواسطة خادم Express،
سيأخذ خادم Express رمز الوصول هذا،
ثم مع معرف العميل الخاص به وسر العميل،
سيتم إرسال هذه المعلومات إلى خادم التفويض.
وسيسمح خادم التفويض بتطبيق العميل الخاص
به بالوصول إلى خادم المورد للحصول على معلومات ملف التعريف.
وبالتالي سيتم إرسال معلومات الملف الشخصي مرة أخرى في الخطوة رقم ستة،
والعودة إلى تطبيق العميل في هذه الحالة.
لذلك عندما يحصل تطبيق العميل على معلومات ملف التعريف للمستخدم،
سيقوم تطبيق العميل بإنشاء حساب جديد
للمستخدم على كل موقع إذا كان الحساب غير موجود.
إذا قام هذا المستخدم بتسجيل الدخول مسبقًا باستخدام معرّف Facebook الخاص به،
فسيكون هناك حساب موجودًا بالفعل بحيث يقوم تطبيق العميل وخادم Rest API
ببساطة بالتقاطع لمعرفة أن حساب المستخدم هذا موجود بالفعل.
وعند هذه النقطة،
تتم مصادقة المستخدم إلى وظيفة تسجيل دخول الطرف الثالث
التي توفرها خدمة مصادقة OAuth 2 في Facebook.
عند هذه النقطة، سيقوم تطبيق العميل بإنشاء JSON Web Token،
في المثال الذي سنقوم بتنفيذه وممارسة الرياضة،
ثم تمرير JSON Web Token مرة أخرى إلى وكيل المستخدم أو تطبيق الواجهة الأمامية،
أو تطبيق Angular، أو التطبيق الأيوني،
أو تطبيق NativeScript.
ثم سيتم استخدام رمز JSON Web Token لاحقًا من قبل المستخدم من
أجل مصادقة نفسه كلما أراد
الوصول إلى أي موارد مخزنة على خادم Express.
لذلك، بمجرد الحصول على JSON Web Token،
جميع العمليات اللاحقة، كنت قد رأيت بالفعل كيفية القيام بذلك مع JSON Web Token.
لذلك، بمجرد الحصول على JSON Web Token
، يتم الانتهاء من عملك،
ومن ثم يمكنك المضي قدما في العملية العادية من تلك النقطة فصاعدا.
الآن، عندما تنتهي صلاحية JSON Web
Token، يجب عليك المرور عبر العملية الكاملة لإعادة مصادقة نفسك، وفي
وقت لاحق، السماح للمستخدمين بالوصول إلى المعلومات على موقعك.
لذلك، مع هذا الفهم السريع لكيفية عمل عمليات OAuth 2
، مرة أخرى، كما ترون، هناك الكثير من التفاصيل هنا.
ولكن، لحسن الحظ، ليس علينا التعامل مع كل هذه التفاصيل لأننا
سنستخدم وحدة عقدة تهتم بالكثير من هذه التفاصيل نيابة عنا.
نظرًا لأننا قمنا بالفعل بإعداد خادم Express الخاص بنا لاستخدام Passport،
يمكننا الآن استخدام رمز وحدة عقدة أخرى كوحدة Passport-Facebook-Token.
تقوم وحدة Passport-Facebook-Token بشكل أساسي بتنفيذ
نهج المنح الضمني الذي تحدثت عنه في وقت سابق.
ومن ثم يمكنك تهيئة
استراتيجية جديدة في استراتيجية جواز السفر الخاص بك، داخل التطبيق الخاص بك.
وهكذا تمكنك وحدة Passport-Facebook-Token من إعداد
استراتيجية مصادقة Passport جديدة لاستخدام واجهة برمجة تطبيقات OAuth 2 المستندة إلى Facebook.
وهكذا للاستفادة من هذه الوحدة،
يمكنك تثبيت هذا بالقول npm الماضي تثبيت جواز السفر - facebook-token
، ناقص الحفظ، وبعد ذلك بمجرد تثبيت
ذلك، ستقوم بتكوين استراتيجية Facebook داخل التطبيق الخاص بك، وبعد ذلك،
الاستفادة من هذا لتكوين الاستراتيجية لجواز السفر الخاص بك
للاستفادة مما إذا كنا نستفيد من المصادقة المستندة إلى OAuth 2 لتطبيقنا.
مع هذا الفهم السريع لـ OAuth 2،
دعنا ننتقل إلى التمرين،
حيث سنقوم بتكوين خادم Express الخاص بنا للاستفادة بالفعل من
نهج المنحة الضمني هذا لتمكيننا
من التحقق من هويتنا إلى خادم Express
، وبعد ذلك، الوصول إلى الموارد، والأطباق،
الترقيات ومعلومات القادة التي يتم تخزينها على خادم إكسبريس لدينا.