لماذا يتمتع OAUTH V2 بالوصول والرموز؟

Question

يشير القسم 4.2 من بروتوكول مشروع OAUTH 2.0 إلى أن خادم التفويض يمكنه إرجاع كلا access_token (الذي يستخدم لمصادقة نفسه بمورد) وكذلك أ refresh_token, ، الذي يستخدم بحتة لإنشاء جديد access_token:

https://tools.ietf.org/html/rfc6749#section-4.2

لماذا كلاهما؟ لماذا لا تصنع فقط access_token يدوم طالما refresh_token وليس لديك refresh_token?

Answer 1

فكرة تحديث الرموز هي أنه إذا تم اختراق رمز الوصول ، لأنه قصير العمر ، فإن المهاجم لديه نافذة محدودة لإساءة استخدامها.

الرموز المميزة للتحديث ، إذا تعرضت للخطر ، غير مجدية لأن المهاجم يتطلب معرف العميل والسر بالإضافة إلى رمز التحديث من أجل الحصول على رمز الوصول.

وقد قلت ذلك, ، لأن كل مكالمة لكل من خادم التفويض وخادم الموارد يتم عبر SSL - بما في ذلك معرف العميل الأصلي وسرية عندما يطلب رمز التحديث طويل الأمد ومجموعة ClientId/Secret.

هذا بالطبع يختلف عن التطبيقات التي لا تتحكم فيها على كل من خوادم التفويض والموارد.

إليك موضوع جيد يتحدث عن استخدامات الرموز المميزة: أرشيف OAUTH.

اقتباس من ما سبق ، يتحدث عن أغراض الأمان لرمز التحديث:

رموز التحديث ... يخفف من خطر تسريب Access_token منذ فترة طويلة (استعلام في ملف سجل على خادم موارد غير آمن أو بيتا أو تطبيق خادم موارد مشفر بشكل سيئ ، عميل JS SDK على موقع غير HTTPS يضع Access_Token في A ملف تعريف الارتباط ، إلخ)

Answer 2

الرابط للمناقشة ، المقدمة من CatchDave ، لديه آخر نقطة صالحة (الرابط الأصلي ، الميت) صنعه ديك هارت ، الذي أعتقد أنه يستحق أن يتم ذكره هنا بالإضافة إلى ما تم كتابته أعلاه:

كانت تذكراتي من رموز التحديث للأمان والالتزام. <...>

إبطال: إذا تم احتواء رمز الوصول ذاتيًا ، فيمكن إلغاء التفويض من خلال عدم إصدار رموز وصول جديدة. لا يحتاج المورد إلى الاستعلام عن خادم التفويض لمعرفة ما إذا كان رمز الوصول صالحًا. هذا يبسط التحقق من صحة الرمز المميز ويسهل توسيع نطاق ودعم خوادم التفويض المتعددة. هناك نافذة من الوقت عندما يكون رمز الوصول صالحًا ، ولكن يتم إلغاء التفويض.

في الواقع ، في الموقف الذي يكون فيه خادم الموارد وخادم التفويض هو نفس الكيان ، وحيث يكون الاتصال بين المستخدم وأي منهما (عادة) آمنًا على قدم المساواة ، ليس هناك معنى كبير للحفاظ على رمز الرمز المميز للوصول.

على الرغم من أنه ، كما هو مذكور في الاقتباس ، يتمثل دور آخر في Refresh Tokens في التأكد من إمكانية إلغاء رمز الوصول في أي وقت من قبل المستخدم (عبر واجهة الويب في ملفاتهم الشخصية ، على سبيل المثال) مع إبقاء النظام قابلاً للتطوير في نفس الوقت .

بشكل عام ، يمكن أن تكون الرموز إما معرفات عشوائية تشير إلى السجل المحدد في قاعدة بيانات الخادم ، أو يمكن أن تحتوي على جميع المعلومات في حد ذاتها (بالتأكيد ، يجب توقيع هذه المعلومات ، مع ماك, ، فمثلا).

كيف يجب أن يعمل النظام ذو الرموز المميزة للوصول منذ فترة طويلة

يسمح الخادم للعميل بالوصول إلى بيانات المستخدم ضمن مجموعة محددة مسبقًا من النطاقات عن طريق إصدار رمز رمزي. نظرًا لأننا نريد الحفاظ على الرمز المميز القابل للإلغاء ، يجب أن نتخزين في قاعدة البيانات الرمز المميز إلى جانب العلم "الذي تم إلغاؤه" الذي يجري تعيينه أو إلغاء تعيينه (وإلا ، كيف يمكنك أن تفعل ذلك باستخدام الرمز المميز القائم بذاته؟) len(users) x len(registered clients) x len(scopes combination) السجلات. كل طلب API ثم يجب أن يضغط على قاعدة البيانات. على الرغم من أنه من التافهة جدًا جعل الاستعلامات إلى قاعدة البيانات هذه التي تؤدي O (1) ، إلا أن النقطة الفردية للفشل نفسها يمكن أن يكون لها تأثير سلبي على قابلية التوسع وأداء النظام.

كيف يجب أن يعمل النظام ذو الرمز المميز للوصول لفترة طويلة والتحديث لفترة قصيرة

هنا نصدر مفتاحين: رمز تحديث عشوائي مع السجل المقابل في قاعدة البيانات ، وتوقيع رمز وصول ذاتي ، يحتوي على حقل الطابع الزمني انتهاء الصلاحية.

نظرًا لأن رمز الوصول مكتفي بذاته ، لا يتعين علينا الوصول إلى قاعدة البيانات على الإطلاق للتحقق من صلاحيتها. كل ما علينا فعله هو فك تشفير الرمز المميز والتحقق من صحة التوقيع والطابع الزمني.

ومع ذلك ، لا يزال يتعين علينا الاحتفاظ بقاعدة بيانات الرموز المميزة للتحديث ، ولكن يتم تعريف عدد الطلبات على قاعدة البيانات هذه بشكل عام من خلال عمر الرمز المميز للوصول (كلما طالت فترة العمر ، كلما انخفض معدل الوصول).

من أجل إلغاء وصول العميل من مستخدم معين ، يجب أن نضع علامة على رمز التحديث المقابل "إلغاء" (أو إزالته تمامًا) والتوقف عن إصدار رموز وصول جديدة. من الواضح على الرغم من أن هناك نافذة تم خلالها إلغاء رمز التحديث ، ولكن قد لا يزال رمز الوصول الخاص به صالحًا.

المقايضات

قم بتحديث الرموز المميزة جزئيًا لإزالة SPOF (نقطة واحدة من الفشل) لقاعدة بيانات الرمز المميز للوصول ، ومع ذلك فإن لديها بعض العيوب الواضحة.

1. النافذة". إطار زمني بين الأحداث "يقوم المستخدم بإلغاء الوصول" و "الوصول إلى إلغاء" الوصول إلى إلغاء ".

2. مضاعفات منطق العميل.

   بدون تحديث الرمز المميز

   • إرسال طلب API مع الرمز المميز للوصول
   • إذا كان الرمز المميز للوصول غير صالح ، ففشل واطلب من المستخدم إعادة صياغة

   مع تحديث الرمز المميز

   • إرسال طلب API مع الرمز المميز للوصول
   • إذا كان رمز الوصول غير صالح ، فحاول تحديثه باستخدام رمز التحديث
   • في حالة مرور طلب التحديث ، قم بتحديث رمز الوصول وأعد تقديم طلب API الأولي
   • في حالة فشل طلب التحديث ، اطلب من المستخدم إعادة صياغة

آمل أن تكون هذه الإجابة منطقية وتساعد شخصًا ما على اتخاذ قرار أكثر تفكيرًا. أود أن أشير أيضًا إلى أن بعض مزودي OAUTH2 المعروفين ، بما في ذلك GitHub و Foursquare Adopt Protocol دون تحديث الرموز المميزة ، ويبدو أنهما سعيدًا بذلك.

Answer 3

على الرغم من كل الإجابات الرائعة أعلاه ، فإنني كطالب ومبرمج أمني أمين عمل سابقًا في موقع eBay عندما ألقيت نظرة على حماية المشتري والاحتيال ، يمكن أن أقول لفصل الرمز المميز للوصول والتحديث له. أفضل توازن بين مضايقة المستخدم متكرر اسم المستخدم/كلمة المرور مدخلات والحفاظ على السلطة في متناول اليد لإلغاء الوصول إلى الإمكانات تعاطي من خدمتك.

فكر في سيناريو مثل هذا. تصدر مستخدمًا لرمز وصول من 3600 ثانية وتحديث الرمز المميز لفترة أطول من يوم واحد.

1. المستخدم هو أ جيد المستخدم ، هو في المنزل ويحصل على/إيقاف موقع الويب الخاص بك للتسوق والبحث على جهاز iPhone الخاص به. لا يتغير عنوان IP الخاص به وله تحميل منخفض للغاية على الخادم الخاص بك. مثل 3-5 صفحة تطلب كل دقيقة. عندما تنتهي 3600 ثانية على رمز الوصول ، فإنه يتطلب واحدة جديدة مع رمز التحديث. نحن ، على جانب الخادم ، نتحقق من تاريخ نشاطه وعنوان IP ، نعتقد أنه إنسان ويتصرف نفسه. نمنحه رمز وصول جديد لمواصلة استخدام خدمتنا. لن يحتاج المستخدم إلى إدخال اسم المستخدم/كلمة المرور مرة أخرى حتى وصل إلى يوم واحد من Tropan من Token Resparme نفسه.

2. المستخدم هو أ غير مبالي المستعمل. هو يعيش في نيويورك ، الولايات المتحدة الأمريكية وحصل على إغلاق برنامج الفيروسات وتم اختراقه من قبل أحد المتسللين في بولندا. عندما يحصل المتسلل على رمز الوصول والتحديث ، يحاول انتحال شخصية المستخدم واستخدام خدمتنا. ولكن بعد انتهاء صلاحية الرمز المميز للوصول القصير ، عندما يحاول المتسلل تحديث رمز الوصول ، لاحظنا ، على الخادم ، تغييرًا كبيرًا في IP في تاريخ سلوك المستخدم (مهلا ، يسجل هذا الرجل في الولايات المتحدة الأمريكية والآن تحديث الوصول في بولندا بعد 3600S فقط ؟؟؟). نقوم بإنهاء عملية التحديث ، وإبطال رمز التحديث نفسه ومطالبة بإدخال اسم المستخدم/كلمة المرور مرة أخرى.

3. المستخدم هو أ ضار المستعمل. يهدف إلى إساءة استخدام خدمتنا من خلال الاتصال بـ 1000 مرة من واجهة برمجة التطبيقات (API) كل دقيقة باستخدام روبوت. يمكنه القيام بذلك حتى 3600 ثانية بعد ذلك ، عندما يحاول تحديث رمز الوصول ، لاحظنا سلوكه ونعتقد أنه قد لا يكون إنسانًا. نرفض وإنهاء عملية التحديث ونطلب منه إدخال اسم المستخدم/كلمة المرور مرة أخرى. هذا قد يحتمل أن يكسر التدفق التلقائي لروبوته. على الأقل يجعله غير مريح.

يمكنك أن ترى رمز التحديث قد تصرف بشكل مثالي عندما نحاول موازنة عملنا وتجربة المستخدم وخطر محتمل لرمز مميز. يمكن للكلب الخاص بك على جانب الخادم التحقق من أكثر من تغيير IP ، وتكرار مكالمات API لتحديد ما إذا كان المستخدم يجب أن يكون مستخدمًا جيدًا أم لا.

كلمة أخرى هي أنه يمكنك أيضًا محاولة الحد من التحكم في الأضرار في الرمز المميز/إساءة استخدام الخدمة المسروقة عن طريق التنفيذ على كل API ، اتصل بكلب ساعة IP الأساسية أو أي تدابير أخرى. ولكن هذا مكلف حيث عليك قراءة وكتابة السجل عن المستخدم وسيؤدي إلى إبطاء استجابة الخادم الخاصة بك.

Answer 4

لا توجد أي من هذه الإجابات إلى السبب الأساسي في أن هناك رموز تحديث. من الواضح أنه يمكنك دائمًا الحصول على زوج جديد للوصول/التحديث عن طريق إرسال بيانات اعتماد العميل إلى خادم Auth-هكذا تحصل عليها في المقام الأول.

لذا فإن الغرض الوحيد من رمز التحديث هو الحد من استخدام بيانات اعتماد العميل التي يتم إرسالها عبر السلك إلى خدمة Auth. كلما كانت TTL أقصر TTL للوصول ، في كثير من الأحيان ، يجب استخدام بيانات اعتماد العميل للحصول على وصول جديد ، وبالتالي فكلما زاد فرص المهاجمين للتسوية لبيانات اعتماد العميل (على الرغم من أن هذا قد يكون صعبًا للغاية على أي حال إذا يتم استخدام التشفير غير المتماثل لإرسالها). لذا ، إذا كان لديك تحديث واحد للاستخدام ، فيمكنك جعل TTL من TTL من توكينات Access صغيرة بشكل تعسفي دون المساس ببيانات اعتماد العميل.

Answer 5

لتوضيح بعض الالتباس ، عليك أن تفهم أدوار سر العميل و ال كلمة مرور المستخدم, والتي تختلف جدا.

ال عميل هو تطبيق/موقع ويب/برنامج/... ، مدعوم بخادم ، يريد ذلك المصادقة أ المستعمل باستخدام خدمة مصادقة الطرف الثالث. سر العميل هو سلسلة (عشوائية) معروفة لكل من العميل وخادم المصادقة. باستخدام هذا السر ، يمكن للعميل التعرف على خادم المصادقة ، والاستلام تفويض لطلب رموز الوصول.

للحصول على الرمز المميز للوصول الأولي ورمز التحديث ، ما هو مطلوب هو:

• معرف المستخدم
• كلمة مرور المستخدم
• معرف العميل
• سر العميل

للحصول على رمز وصول منتعش ولكن عميل يستخدم المعلومات التالية:

• معرف العميل
• سر العميل
• رمز التحديث

يوضح هذا الفرق بوضوح: عندما ينشق العميل ، يتلقى العميل تفويضًا لتحديث الرموز المميزة باستخدام سر العميل ، وبالتالي يمكنه إعادة مصادف المستخدم باستخدام رمز التحديث في حين أن معرف المستخدم + كلمة المرور. هذا يمنع المستخدم بشكل فعال من الاضطرار إلى إعادة إدخال كلمة المرور الخاصة به.

يوضح هذا أيضًا أن فقدان رمز التحديث ليس مشكلة لأن معرف العميل والسر غير معروفان. كما يوضح أن الحفاظ على معرف العميل وسرية العميل هو مهم للغاية.

Answer 6

هذه الإجابة هي من جاستن ريتشر عبر قائمة البريد الإلكتروني القياسية في Oauth 2. تم نشر هذا بإذنه.

---

إن عمر الرمز المميز لتحديثه يصل إلى خادم التفويض (AS) - يمكن أن تنتهي صلاحيته ، وإلغاء ، وما إلى ذلك. الفرق بين رمز التحديث ورمز الوصول هو الجمهور: الرمز المميز للتحديث يعود فقط إلى خادم التفويض ، ينتقل رمز الوصول إلى خادم الموارد (RS).

أيضًا ، لا يعني مجرد الحصول على رمز الوصول إلى تسجيل الدخول. في الواقع ، قد لا يكون المستخدم هناك بعد الآن ، وهي في الواقع حالة الاستخدام المقصود لرمز التحديث. إن تحديث الرمز المميز للوصول سيتيح لك الوصول إلى واجهة برمجة تطبيقات نيابة عن المستخدم ، ولن يخبرك ما إذا كان المستخدم هناك.

لا يمنحك OpenID Connect معلومات المستخدم فقط من رمز الوصول ، بل يمنحك أيضًا رمزًا للمعرف. هذه جزء منفصل من البيانات الموجهة إلى العميل نفسه ، وليس AS أو RS. في OIDC ، يجب عليك فقط التفكير في "تسجيل الدخول" في الواقع بواسطة البروتوكول إذا كان يمكنك الحصول على رمز معرف جديد. منعش من غير المحتمل أن يكون كافيا.

لمزيد من المعلومات يرجى القراءة http://oauth.net/articles/authentication/

Answer 7

يمكن أن يتعرض العملاء للخطر بعدة طرق. على سبيل المثال ، يمكن استنساخ الهاتف الخليوي. إن انتهاء صلاحية الوصول إلى الرمز المميز يعني أن العميل يُجبر على إعادة صياغة خادم التفويض. أثناء إعادة المصادقة ، يمكن لخادم التفويض التحقق من الخصائص الأخرى (IOW يؤدي إدارة الوصول التكيفي).

تسمح الرموز المميزة لتحديث العميل فقط بإعادة المصادقة ، حيث يعيد تفويض الحوار مع المستخدم الذي أشار إليه الكثيرون أنهم يفضلون عدم القيام به.

تتناسب الرموز المميزة لتحديث بشكل أساسي في نفس المكان الذي قد تختار فيه مواقع الويب العادية إعادة صياغة المستخدمين بشكل دوري بعد ساعة أو نحو ذلك (على سبيل المثال الموقع المصرفي). لا يتم استخدامه بشكل كبير في الوقت الحالي لأن معظم مواقع الويب الاجتماعية لا تعيد مصادقة مستخدمي الويب ، فلماذا يعيدون مصادر العميل؟

Answer 8

لزيادة تبسيط إجابة BT: استخدم Refresh Tokens عندما لا تريد عادةً أن يضطر المستخدم إلى كتابة بيانات الاعتماد مرة أخرى ، ولكن لا تزال ترغب في أن تكون القدرة على إلغاء الأذونات (عن طريق إلغاء رمز التحديث)

لا يمكنك إلغاء رمز الوصول ، فقط رمز تحديث.

Answer 9

لماذا لا تجعل Access_token يدوم طالما أن refresh_token وليس لديك refresh_token؟

بالإضافة إلى الإجابات الرائعة التي قدمها أشخاص آخرون ، هناك سبب آخر لاستخدام الرموز المميزة للتحديث وعلى المطالبات.

يحتوي كل رمز على مطالبات يمكن أن تتضمن أي شيء من اسم المستخدمين أو أدوارهم أو المزود الذي أنشأ المطالبة. كما يتم تحديث الرمز المميز ، يتم تحديث هذه المطالبات.

إذا قمنا بتحديث الرموز في كثير من الأحيان ، فمن الواضح أننا نضع المزيد من الضغط على خدمات هويتنا ، لكننا نحصل على مطالبات أكثر دقة وحديثًا.

Answer 10

افترض أنك تصنع access_token يدوم طويلًا جدًا ، وليس لديك refresh_token, ، لذلك في يوم واحد ، احصل المتسلل على هذا access_token ويمكنه الوصول إلى جميع الموارد المحمية!

ولكن إذا كان لديك refresh_token, ، ال access_tokenالوقت الحي قصير ، لذلك يصعب اختراق المتسلل الخاص بك access_token لأنه سيكون غير صالح بعد فترة قصيرة من الزمن.Access_token لا يمكن استردادها إلا باستخدام ليس فقط refresh_token ولكن أيضا من قبل client_id و client_secret, ، أي هاكر لا يملكه.

Answer 11

بينما يتم الاحتفاظ بالرمز المميز للتحديث بواسطة خادم التفويض. الرمز المميز للوصول مكتفية ذاتيًا حتى يتمكن خادم الموارد من التحقق منه دون تخزينه مما يوفر جهود الاسترجاع في حالة التحقق من الصحة. نقطة أخرى مفقودة في المناقشة هي من RFC6749#صفحة 55

"على سبيل المثال ، يمكن أن يستخدم خادم التفويض دوران مميز تحديث يتم فيه إصدار رمز تحديث جديد مع كل استجابة لتحديث الرمز المميز. كل من المهاجم والعميل الشرعي ، سيقدم أحدهما رمزًا تحديثًا مبطلًا ، والذي سيبلغ خادم التفويض بالخرق. "

أعتقد أن الهدف الكامل لاستخدام رمز التحديث هو أنه حتى لو تمكن المهاجم بطريقة ما من الحصول على رمز الرمز المميز ومعرف العميل والمزيج السري. مع المكالمات اللاحقة للحصول على رمز الوصول الجديد من المهاجم يمكن تتبعه في حالة ما إذا كان كل طلب للتحديث يؤدي إلى رمز وصول جديد وعملية تحديث الرمز المميز.

Answer 12

تم وضع هذه الإجابة بمساعدة اثنين من كبار ديف (جون برايتون وديفيد جينيس).

السبب الرئيسي لاستخدام رمز تحديث هو تقليل سطح الهجوم.

لنفترض أنه لا يوجد مفتاح تحديث ودعنا نذهب من خلال هذا المثال:

المبنى لديه 80 باب. يتم فتح جميع الأبواب بنفس المفتاح. يتغير المفتاح كل 30 دقيقة.

إذا كنت القراصنة وحصلت على مفتاحك ، فعندئذ في نهاية الثلاثين دقيقة ، فسوف ستعمل على ذلك إلى مفتاح Keymaker وأحصل على مفتاح جديد. سأكون قادرًا على فتح جميع الأبواب باستمرار بغض النظر عن تغيير المفتاح.

سؤال: خلال الثلاثين دقيقة ، كم عدد فرص الاختراق التي حصلت عليها ضد المفتاح؟ كان لدي 80 فرصًا للقرصنة ، في كل مرة تستخدم فيها المفتاح (فكر في هذا على أنه تقديم طلب شبكة وتمرير رمز الوصول لتحديد هويتك). هذا هو سطح الهجوم 80x.

الآن دعنا نذهب إلى نفس المثال ولكن هذه المرة لنفترض أن هناك مفتاح تحديث.

المبنى لديه 80 باب. يتم فتح جميع الأبواب بنفس المفتاح. يتغير المفتاح كل 30 دقيقة. إذا كنت المتسلل وحصلت على مفتاحك ، فيمكنني استخدامه لمدة 30 دقيقة ، ولكن في نهاية 30 دقيقة أرسله إلى Keymaker ليس له قيمة. إذا قمت بذلك ، فإن صانع المفاتيح يقول إن هذا المفتاح قد انتهى. لكي أكون قادرًا على تمديد الاختراق الخاص بي ، سيتعين عليّ اختراق البريد السريع إلى The Keymaker. لدى Courier مفتاح متميز (فكر في هذا كرمز لتحديث).

سؤال: خلال الثلاثين دقيقة ، كم عدد فرص الاختراق التي حصلت عليها ضد البريد السريع؟ 80؟ لا. لقد حصلت على فرصة واحدة فقط. خلال الوقت الذي يتواصل فيه البريد السريع مع Keymaker. هذا هو سطح الهجوم 1x. كان لدي 80 فرصة للقرصنة ضد المفتاح ، لكنها ليست جيدة بعد 30 دقيقة.

---

سيقوم الخادم بالتحقق من رمز الوصول بناءً على بيانات الاعتماد وتوقيع (عادةً) JWT.

يعد تسرب الرمز المميز للوصول سيئًا ، ولكن بمجرد انتهاء صلاحيته ، لم يعد مفيدًا للمهاجم. إن تسرب الرمز المميز للتحديث أسوأ بكثير ، لكن من المفترض أنه أقل احتمالًا. (أعتقد أن هناك مجالًا للتساؤل عما إذا كان احتمال تسرب رمز تحديث أقل بكثير من تسرب الرمز المميز ، ولكن هذه هي الفكرة.)

النقطة هي أنه يتم إضافة رمز الوصول إلى كل طلب تقدمه ، في حين يتم استخدام رمز التحديث فقط أثناء تدفق التحديث ، لذا فإن فرصة أقل لرؤية الرمز المميز

التردد يساعد المهاجم. القلب-على غرار عيوب الأمان المحتملة في SSL ، فإن عيوب الأمان المحتملة في العميل ، والعيوب الأمنية المحتملة في الخادم تجعل كلها متسربة.

بالإضافة إلى ذلك ، إذا كان خادم التفويض منفصلًا عن خادم التطبيق الذي يقوم بمعالجة طلبات العميل الأخرى ، فلن يرى خادم التطبيق هذا أبدًا رموز التحديث. سيشهد فقط رموز الوصول التي لن تعيش لفترة أطول.

التقسيم هو مفيد للأمن.

---

ما هو رمز التحديث الذي لا يدور حوله؟

إن القدرة على تحديث/إبطال مستوى الوصول من خلال Refresh Tokens هي نتيجة ثانوية لاختيار استخدام الرموز المميزة للتحديث ، وإلا يمكن إلغاء رمز الوصول المستقل أو تعديل مستوى وصوله عندما ينتهي صلاحيته ويحصل المستخدمون على رمز جديد "

Answer 13

دعونا نفكر في نظام يرتبط كل مستخدم بأدوار واحدة أو أكثر ويتم ربط كل دور بامتيازات الوصول أو أكثر. يمكن تخزين هذه المعلومات مؤقتًا لتحسين أداء واجهة برمجة التطبيقات. ولكن بعد ذلك ، قد تكون هناك تغييرات في تكوينات المستخدم والدور (على سبيل المثال ، قد يتم منح الوصول الجديد أو قد يتم إلغاء الوصول الحالي) ويجب أن تنعكس في ذاكرة التخزين المؤقت.

يمكننا استخدام الرموز المميزة للوصول وتحديثها لهذا الغرض. عندما يتم استدعاء واجهة برمجة تطبيقات مع رمز الوصول ، يقوم خادم المورد بالتحقق من ذاكرة التخزين المؤقت لحقوق الوصول. إذا كان هناك أي منح وصول جديدة ، فهي لا تنعكس على الفور. بمجرد انتهاء مميز الوصول (على سبيل المثال في 30 دقيقة) ويستخدم العميل رمز التحديث لإنشاء رمز وصول جديد ، يمكن تحديث ذاكرة التخزين المؤقت مع معلومات وصول المستخدم المحدثة من DB.

بمعنى آخر ، يمكننا نقل العمليات باهظة الثمن من كل مكالمة API باستخدام رموز الوصول إلى حالة توليد الرمز المميز للوصول باستخدام Trefl Token.

Answer 14

أولاً ، يقوم العميل بإصدار مصادقة خادم التفويض من خلال منح منحة التفويض.

بعد ذلك ، يطلب العميل خادم الموارد للمورد المحمي من خلال إعطاء رمز الوصول.

يقوم خادم الموارد بالتحقق من صحة الرمز المميز للوصول ويوفر المورد المحمي.

يقدم العميل طلب المورد المحمي إلى خادم الموارد عن طريق منح رمز الوصول ، حيث يقوم خادم المورد بالتحقق منه ويخدم الطلب ، إذا كان صالحًا. تستمر هذه الخطوة في التكرار حتى تنتهي صلاحية رمز الوصول.

إذا انتهت صلاحية الرمز المميز للوصول ، فإن العميل يصادق مع خادم التفويض ويطلب رمز الوصول الجديد من خلال توفير رمز تحديث. إذا كان رمز الوصول غير صالح ، فإن خادم المورد يعيد استجابة خطأ الرمز المميز غير الصحيح إلى العميل.

يقوم العميل المصادقة باستخدام خادم التفويض من خلال منح رمز التحديث.

ثم يقوم خادم التفويض بالتحقق من صحة رمز التحديث عن طريق مصادقة العميل ويصدر رمز الوصول الجديد ، إذا كان صحيحًا.