الرمز الغامض مقابل JWT
فهم الفروقات بين الرموز الغامضة وJWT، حالات استخدامها، وكيفية التحقق من صحتها في أنظمة OIDC.
فهم الفروقات بين الرموز الغامضة وJWT، حالات استخدامها، وكيفية التحقق من صحتها في أنظمة OIDC.
في Logto، كمنصة CIAM شاملة قائمة على OIDC، تلعب رموز الأذونات دوراً حيوياً في تأمين تفاعلات المستخدم وإدارة الوصول إلى الموارد. من بين الأنواع المختلفة للرموز المستخدمة لأغراض الأذونات، تعد الرموز الغامضة وJWT (رموز الويب JSON) الأكثر أهمية.
لقد تلقينا عدة أسئلة من مجتمعنا، مثل: ما هو الفرق بين الرمز الغامض وJWT؟ ولماذا لا أستطيع فك تشفير رمز الوصول الذي استلمته، ولماذا يبدو طول الرمز قصيراً؟ يهدف هذا المنشور إلى توضيح هذه المفاهيم ومساعدتك على فهم التمييز بين الرموز الغامضة وJWT، حالات استخدامها، ولماذا قد تصادف سلوكيات مختلفة أثناء العمل معها.
الرمز الغامض هو نوع من رموز الوصول الذي، كما يشير الاسم، يكون غير قابل للشفافية للعميل أو أي طرف خارجي. وهذا يعني أن الرمز نفسه لا يحمل أي معلومات يمكن قراءتها عن المستخدم أو الأذن الممنوح.
عند استلامك رمز غامض، فإنه غالباً ما يظهر كسلسلة عشوائية من الأحرف، ومحاولة لفك تشفيره لن ينتج عنها أي بيانات ذات معنى.
إليك مثال على رمز غامض:
نظرًا لأن المحتوى الفعلي للرمز معروف فقط لخادم الأذونات الذي قام بإصداره، يحتاج العميل إلى إعادته إلى الخادم، الذي يتحقق بعد ذلك من صحة الرمز ويحدد الأذونات المرتبطة به. يضمن هذا النهج أن تظل المعلومات الحساسة مخفية، مما يوفر طبقة أمان إضافية، ولكنه يتطلب أيضاً اتصالات إضافية مع الخادم للتحقق من صحة الرمز.
الإيجابيات:
السلبيات:
على النقيض من الرموز الغامضة، يعتبر JWT (رمز الويب JSON) رمزاً ذاتي المحتوى وغير معتمد على الحالة ويحمل المعلومات في شكل منظم وقابل للقراءة.
يتكون JWT من ثلاثة أجزاء: header، payload، وsignature، وكلها مشفرة بواسطة Base64URL.
إليك مثال على JWT:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cheader على معلومات حول نوع الرمز والخوارزمية المستخدمة للتوقيع. على سبيل المثال، {"alg": "HS256", "typ": "JWT"}.payload على ادعاءات - قطع من المعلومات حول المستخدم أو الأذن - مثل معرف المستخدم، وقت انتهاء الصلاحية، والنطاقات. ولأن هذه البيانات مشفرة ولكنها ليست مشفرة، فيمكن لأي شخص لديه الرمز فك تشفيره لرؤية الادعاءات، على الرغم من أنه لا يمكن تعديلها دون إبطال التوقيع. استناداً إلى المواصفات وتكوين خادم الأذونات، يمكن تضمين ادعاءات مختلفة في قسم payload. هذا يعطي الرمز طبيعته الذاتية. على سبيل المثال، {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.signature بدمج الheader, payload, ومفتاح سري باستخدام الخوارزمية المحددة. يستخدم هذا التوقيع للتحقق من سلامة الرمز وللتأكد من أنه لم يتم التلاعب به.تُستخدم رموز JWT بشكل شائع لأنها يمكن التحقق منها محليًا بواسطة العميل أو أي خدمة، دون الحاجة إلى التفاعل مع خادم الأذونات. يجعل هذا من رموز JWT فعالة بشكل خاص للأنظمة الموزعة، حيث قد تحتاج خدمات متعددة إلى التحقق من صحة الرمز بشكل مستقل.
ومع ذلك، تأتي هذه السهولة أيضًا مع مسؤولية ضمان أن ادعاءات الرمز لا تكشف بشكل مفرط، حيث تكون مرئية لأي شخص لديه الوصول إلى الرمز. كما تُعَدّ رموز JWT قصيرة العمر بشكل عام، ويتم تضمين وقت انتهاء الصلاحية في ادعاءات الرمز لضمان أنها غير صالحة بشكل لا نهائي.
الإيجابيات:
السلبيات:
يتم التحقق من صحة رمز الوصول الغامض عن طريق إرساله مرة أخرى إلى خادم الأذونات للتحقق. يحافظ خادم الأذونات على حالة الرموز الصادرة ويمكنه تحديد صحة الرمز استنادًا إلى التخزين الداخلي له.
يمكن التحقق من صحة رمز الوصول JWT بشكل غير متصل بالإنترنت من قبل العميل أو أي خدمة تملك الوصول إلى المفتاح العام للرمز.
في سياق OIDC (OpenID Connect)، تخدم الرموز الغامضة وJWT أغراضًا مختلفة وتُستخدم في سيناريوهات محددة.
بشكل افتراضي، عندما يطلب العميل رمز وصول بدون تحديد مورد ويتضمن نطاق openid، يصدر خادم الأذونات رمز وصول غامض. هذا الرمز يُستخدم أساسًا لاسترجاع معلومات ملف المستخدم الشخصي من نقطة النهاية /oidc/userinfo الخاصة بـOIDC. عند استلام طلب مع رمز وصول غامض، يتحقق خادم الأذونات من تخزينه الداخلي لاستخراج معلومات الأذونات المرتبطة ويؤكد صحة الرمز قبل الاستجابة بتفاصيل ملف المستخدم الشخصي.
تصمم رموز التحديث للتبادل فقط بين العميل وخادم الأذونات، دون الحاجة لمشاركتها مع مزودي الموارد. ولهذا، تُصدر رموز التحديث عادة كرموز غامضة. عندما ينتهي صلاحية رمز الوصول الحالي، يمكن للعميل استخدام رمز التحديث الغامض للحصول على رمز وصول جديد، مما يضمن الوصول المستمر دون إعادة مصادقة المستخدم.
في OIDC، يكون رمز المعرف هو JWT يحتوي على معلومات المستخدم ويستخدم لمصادقة المستخدم. يُصدر عادةً إلى جانب رمز الوصول، ويسمح للعميل بالتحقق من هوية المستخدم. على سبيل المثال:
يمكن للعميل التحقق من صحة رمز المعرف لضمان هوية المستخدم واستخراج معلومات المستخدم لأغراض التخصيص أو الأذونات. رمز المعرف مخصص للاستخدام لمرة واحدة فقط ولا ينبغي استخدامه لأذونات موارد API.
عندما يطلب العميل رمز وصول مع مؤشر مورد معين، يصدر خادم الأذونات رمز وصول JWT مخصص للوصول إلى ذلك المورد. يحتوي JWT على ادعاءات يمكن لمزود الموارد استخدامها للسماح بوصول العميل. على سبيل المثال:
يمكن لمزود الموارد التحقق من صحة الطلب عن طريق التحقق من الادعاءات:
iss: يؤكد أن الرمز تم إصداره بواسطة خادم أذونات موثوق.sub: يحدد المستخدم المرتبط بالرمز.aud: يضمن أن الرمز مخصص للمورد المحدد.scope: يتحقق من الأذونات الممنوحة للمستخدم.باختصار، تخدم الرموز الغامضة وJWT أغراضًا مختلفة في أنظمة OIDC، حيث توفر الرموز الغامضة نهجًا آمنًا ومعتمدًا على الحالة للأذونات وتوفر JWTs بديلاً ذاتي المحتوى وغير معتمد على الحالة. فهم الاختلافات بين هذه الأنواع من الرموز وحالات استخدامها ضروري لتصميم آليات مصادقة وأذونات آمنة وفعالة في تطبيقاتك.
اكتشف المزيد من ميزات رموز الوصول في Logto: