الرمز الغامض مقابل JWT

في Logto، كمنصة CIAM شاملة قائمة على OIDC، تلعب رموز الأذونات دوراً حيوياً في تأمين تفاعلات المستخدم وإدارة الوصول إلى الموارد. من بين الأنواع المختلفة للرموز المستخدمة لأغراض الأذونات، تعد الرموز الغامضة وJWT (رموز الويب JSON) الأكثر أهمية.

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

ما هو الرمز الغامض؟#

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

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

إليك مثال على رمز غامض:

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

الإيجابيات:

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

السلبيات:

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

ما هو JWT؟#

على النقيض من الرموز الغامضة، يعتبر JWT (رمز الويب JSON) رمزاً ذاتي المحتوى وغير معتمد على الحالة ويحمل المعلومات في شكل منظم وقابل للقراءة.

يتكون JWT من ثلاثة أجزاء: header، payload، وsignature، وكلها مشفرة بواسطة Base64URL.

إليك مثال على JWT:

• يحتوي header على معلومات حول نوع الرمز والخوارزمية المستخدمة للتوقيع. على سبيل المثال، {"alg": "HS256", "typ": "JWT"}.
• تحتوي قسم payload على ادعاءات - قطع من المعلومات حول المستخدم أو الأذن - مثل معرف المستخدم، وقت انتهاء الصلاحية، والنطاقات. ولأن هذه البيانات مشفرة ولكنها ليست مشفرة، فيمكن لأي شخص لديه الرمز فك تشفيره لرؤية الادعاءات، على الرغم من أنه لا يمكن تعديلها دون إبطال التوقيع. استناداً إلى المواصفات وتكوين خادم الأذونات، يمكن تضمين ادعاءات مختلفة في قسم payload. هذا يعطي الرمز طبيعته الذاتية. على سبيل المثال، {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• يتم إنشاء signature بدمج الheader, payload, ومفتاح سري باستخدام الخوارزمية المحددة. يستخدم هذا التوقيع للتحقق من سلامة الرمز وللتأكد من أنه لم يتم التلاعب به.

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

ومع ذلك، تأتي هذه السهولة أيضًا مع مسؤولية ضمان أن ادعاءات الرمز لا تكشف بشكل مفرط، حيث تكون مرئية لأي شخص لديه الوصول إلى الرمز. كما تُعَدّ رموز JWT قصيرة العمر بشكل عام، ويتم تضمين وقت انتهاء الصلاحية في ادعاءات الرمز لضمان أنها غير صالحة بشكل لا نهائي.

الإيجابيات:

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

السلبيات:

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

التحقق من صحة رمز الوصول الغامض#

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

1. يطلب العميل رمز وصول من خادم الأذونات.
2. يقوم خادم الأذونات بإصدار رمز غامض.
3. يرسل العميل طلب الوصول إلى الموارد مع الرمز الغامض في الرأس.
4. يرسل مزود الموارد طلب فحص الرمز إلى خادم الأذونات للتحقق من صحة الرمز.
5. يستجيب خادم الأذونات بمعلومات الرمز.

التحقق من صحة رمز الوصول JWT (غير متصل بالإنترنت)#

يمكن التحقق من صحة رمز الوصول JWT بشكل غير متصل بالإنترنت من قبل العميل أو أي خدمة تملك الوصول إلى المفتاح العام للرمز.

0. يقوم مزود الموارد بجلب مفتاح خادم الأذونات العام مسبقًا من نقطة اكتشاف OIDC. يستخدم المفتاح العام للتحقق من توقيع الرمز وضمان سلامته.
1. يطلب العميل رمز وصول من خادم الأذونات.
2. يصدر خادم الأذونات رمز JWT.
3. يرسل العميل طلب الوصول إلى الموارد مع رمز JWT في الرأس.
4. يقوم مزود الموارد بفك وتحقق من صحة رمز JWT باستخدام المفتاح العام الذي تم الحصول عليه من خادم الأذونات.
5. يمنح مزود الموارد الوصول استنادًا إلى صلاحية الرمز.

حالات الاستخدام في OIDC#

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

الرموز الغامضة#

1. استرجاع ملف المستخدم الشخصي:

بشكل افتراضي، عندما يطلب العميل رمز وصول بدون تحديد مورد ويتضمن نطاق openid، يصدر خادم الأذونات رمز وصول غامض. هذا الرمز يُستخدم أساسًا لاسترجاع معلومات ملف المستخدم الشخصي من نقطة النهاية /oidc/userinfo الخاصة بـOIDC. عند استلام طلب مع رمز وصول غامض، يتحقق خادم الأذونات من تخزينه الداخلي لاستخراج معلومات الأذونات المرتبطة ويؤكد صحة الرمز قبل الاستجابة بتفاصيل ملف المستخدم الشخصي.

2. تبادل رمز التحديث:

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

JWTs#

1. رمز المعرف:

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

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

2. الوصول إلى موارد API:

عندما يطلب العميل رمز وصول مع مؤشر مورد معين، يصدر خادم الأذونات رمز وصول JWT مخصص للوصول إلى ذلك المورد. يحتوي JWT على ادعاءات يمكن لمزود الموارد استخدامها للسماح بوصول العميل. على سبيل المثال:

يمكن لمزود الموارد التحقق من صحة الطلب عن طريق التحقق من الادعاءات:

• iss: يؤكد أن الرمز تم إصداره بواسطة خادم أذونات موثوق.
• sub: يحدد المستخدم المرتبط بالرمز.
• aud: يضمن أن الرمز مخصص للمورد المحدد.
• scope: يتحقق من الأذونات الممنوحة للمستخدم.

الخاتمة#

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

اكتشف المزيد من ميزات رموز الوصول في Logto:

• استخدام RBAC لحماية API الخاص بك
• رمز الوصول للمؤسسة
• الادعاءات المخصصة في JWT