العربية
  • oidc
  • oauth
  • token-exchange
  • openid

فهم تبادل الرموز في OAuth/OIDC

تبادل الرموز هو امتداد لـ OAuth يتيح للعملاء الموثوقين الحصول على رموز جديدة دون تدخل المستخدم، وهو مفيد للانتحال والأتمتة والتكامل عبر الأنظمة المختلفة والهجرة في سيناريوهات متنوعة.

Sijie
Sijie
Developer

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

مقارنة مع عملية تدفق رمز الترخيص

لنلقِ نظرة أولاً على عملية تدفق رمز الترخيص في OAuth، وهي العملية الأكثر شيوعًا للحصول على رمز وصول.

وهذه هي عملية تدفق تبادل الرموز:

إعادة التوجيه

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

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

مصدر الرموز وخدمة تبادل الرموز

في عملية تبادل الرموز، يصبح "الخادم الموثّق" الآن مشاركين:

  1. مصدر الرموز: يصدر رمز الموضوع لتطبيق العميل.
  2. خدمة تبادل الرموز: تتحقق من صحة رمز الموضوع وتصدر رمزًا جديدًا لتطبيق العميل.

تعد خدمة تبادل الرموز نفس "الخادم الموثّق" في عملية تدفق رمز الترخيص، ويمكن أن يكون مصدر الرموز موفر هوية طرف ثالث، أو مفصول من "الخادم الموثّق" كخدمة مخصصة.

متى يجب استخدام تبادل الرموز؟

يمكن تنفيذ تدفق تبادل الرموز بدون تدخل المستخدم، وهذا مفيد في السيناريوهات التالية:

  • الانتحال: يتيح للخدمات (مثل الخدمات الدقيقة للخلفية) أو للمسؤولين تنفيذ الإجراءات نيابة عن المستخدم دون كشف كامل لبيانات اعتماد المستخدم.
  • الأتمتة: يتيح للخدمات الموثوقة تنفيذ الإجراءات تلقائيًا دون تدخل يدوي، أو تنفيذ اختبارات تلقائية.
  • التكامل مع موفري الهوية الآخرين: ترجمة الرموز عبر أنظمة الهوية المختلفة للحفاظ على تجربة مستخدم سلسة وإدارة الأذونات بشكل فعال، أحد السيناريوهات الشائعة هو ترجمة رمز SSO إلى رمز لخدمة متدفقة.
  • الهجرة: هجرة الرموز من خادم ترخيص إلى آخر، على سبيل المثال، من نظام قديم إلى نظام حديث متوافق مع OAuth/OIDC.

عملية تبادل الرموز

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

تطبيق العميل

لتنفيذ تبادل الرموز، يتطلب وجود تطبيق عميل مسجل لدى خادم الترخيص.

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

طلب تبادل الرموز

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

  1. grant_type: مطلوب. يجب أن تكون قيمة هذه المعلمة urn:ietf:params:oauth:grant-type:token-exchange مما يشير إلى أن تبادل الرموز يتم تنفيذه.
  2. subject_token: مطلوب. رمز PAT الخاص بالمستخدم.
  3. subject_token_type: مطلوب. نوع رمز الأمان المقدم في معلمة subject_token. قيمة شائعة لهذه المعلمة هي urn:ietf:params:oauth:token-type:access_token، ولكن يمكن أن تختلف بناءً على الرمز الذي يتم تبادله.
  4. resource: اختياري. مؤشر المورد، يساعد في تحديد المورد المستهدف لرمز الوصول.
  5. audience: اختياري. جمهور رمز الوصول، يشير إلى المستلمين المقصودين للرمز، قد يستخدم خادم الترخيص قيمة resource إذا لم يتم تحديد audience.
  6. scope: اختياري. النطاقات المطلوبة.

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

هنا مثال على الطلب:

تبادل الرموز في Logto

يدعم Logto تبادل الرموز مباشرة، بما في ذلك الانتحال و الرموز الشخصية.