oauth 2.0oidc

ما هو رمز مبهم (Opaque token)؟

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

ما هو الرمز المبهم (Opaque token)؟

عادةً ما يتم إنشاء الرموز المبهمة باستخدام مولد الأرقام العشوائية الزائفة الآمن من الناحية التشفيرية (CSPRNG) لضمان عدم القدرة على التنبؤ بها وأمانها، ويتم تحديد تنسيقها بواسطة مصدرها.

إليك مثال على رمز مبهم:

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

ما هو الفرق بين JWT (JSON Web Token) والرمز المبهم (Opaque token)؟

يكمن الفرق الرئيسي في كيفية تعامل هذه الرموز مع معلومات التفويض والتحقق منها:

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

JWT هو رمز مستقل يحتوي على جميع المعلومات الضرورية بداخله.

إليك مثال على JWT، وهو سلسلة مشفرة بتنسيق base64:

eyJhbGciOiJIUzI1NiIs.eyJzdWIiOiIxMjM0NTY3O.SflKxwRJSMeKKF2QT4f

ويحتوي على ثلاثة أجزاء مفصولة بنقاط:

الرأس (Header) - يحتوي على معلومات حول نوع الرمز والخوارزمية المستخدمة للتوقيع. على سبيل المثال، {"alg": "HS256", "typ": "JWT"}.
الحمولة (Payload) - تحتوي على المطالبات—معلومات حول المستخدم أو التفويض، مثل معرف المستخدم، وقت الانتهاء، والنطاقات. يمكن لأي شخص فك تشفيرها لرؤية المطالبات لأنها مشفرة وليست مشفرة.
التوقيع (Signature) - يتم إنشاؤه عن طريق دمج الرأس والحمولة ومفتاح سري باستخدام الخوارزمية المحددة. يُستخدم هذا التوقيع للتحقق من سلامة الرمز وضمان عدم التلاعب به.

تسمح هذه البنية لـ JWTs بالتحقق والاستخدام دون استعلام قاعدة البيانات.

لمزيد من المعلومات التفصيلية حول JWTs، يرجى الرجوع إلى رمز الويب جيسون (JSON Web Token, JWT) .

وتحقق من الرمز المبهم مقابل JWT لمعرفة المزيد عن اختلافاتهم بعمق أكبر.

كيفية التحقق من الرمز المبهم (Opaque token)

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

في الأنظمة متعددة الأطراف التي تقدم OAuth 2.0، قد تحتاج خوادم الموارد المتعددة (انظر: خادم الموارد (Resource server) ) إلى التحقق من نفس الرمز المبهم. يوفر OAuth 2.0 آلية استعراض الرموز القياسية لهذا التحقق:

لمزيد من المعلومات التفصيلية حول استعراض الرموز، يرجى الرجوع إلى تفتيش الرمز المميز (Token introspection) .

كيف تُستخدم الرموز المبهمة (Opaque tokens) في OIDC؟

في سياق OIDC ( OpenID Connect (OIDC) )، تخدم الرموز المبهمة أغراضًا محددة في سيناريوهات مختلفة:

استرداد ملف تعريف المستخدم

افتراضيًا، عندما يطلب العميل رمز وصول دون تحديد مورد ويشمل نطاق openid، يقوم خادم التفويض بإصدار رمز وصول مبهم. يُستخدم هذا الرمز بشكل أساسي لاسترداد معلومات ملف تعريف المستخدم من نقطة نهاية OIDC /oidc/userinfo (انظر: نقطة نهاية معلومات المستخدم (Userinfo endpoint) ).

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

عادةً ما تُصدر رموز التحديث (انظر: رمز التجديد (Refresh token) ) كرموز مبهمة لأنها تُبادل فقط بين العميل وخادم التفويض. عندما ينتهي صلاحية رمز الوصول الحالي، يمكن للعميل استخدام رمز التحديث المبهم للحصول على رمز وصول جديد دون إعادة التحقق من المستخدم.

ما هي مزايا وعيوب الرمز المبهم (Opaque token)؟

المزايا

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

العيوب

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