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

ما هو الرمز؟

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

تُستخدم الرموز لتمثيل ونقل المعلومات الآمنة بين الأطراف، وهي تدعم الغالبية العظمى من عمليات مصادقة (Authentication) و التفويض (Authorization) التي تحدث على الإنترنت خلف الكواليس. النوعان الأكثر شيوعًا من الرموز في خدمات الويب هما رمز الويب جيسون (JSON Web Token, JWT) والرموز المبهمة.

ما هو الرمز المبهم؟

الرموز المبهمة هي رموز في صيغة خاصة لا يمكنك الوصول إليها وعادة ما تحتوي على بعض المعرفات للمعلومات في التخزين الدائم للخادم.

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

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

من ناحية أخرى، JWT هو صيغة رمز شائعة أخرى. إنه سلسلة JSON تحتوي على جميع المطالبات والمعلومات، إلى جانب توقيع من المُصدر. بشكل افتراضي، لا يتم تشفيره، على الرغم من أنه يمكن تشفيره باستخدام معيار تشفير الويب بصيغة JSON (JSON Web Encryption, JWE) . على الرغم من أن JWT عادة ما يكون غير مشفر، إلا أنه لا يضر بأمانه - وجود التوقيع يضمن سلامة محتويات الرمز، مما يسمح بالثقة الكاملة في البيانات داخل JWT.

على عكس JWT، الذي يحتوي على جميع المعلومات اللازمة للتحقق المباشر في المورد المحمي، لا يمكن التحقق من الرموز المبهمة مباشرة من قبل المورد. بدلاً من ذلك، تتطلب التحقق من قبل مُصدر الرمز المبهم (عادةً خادم التفويض (Authorization server) ). تُعرف عملية التحقق هذه عادةً باسم تفتيش الرمز المميز (Token introspection) .

ما هو JWT؟

على النقيض من الرموز المبهمة، JWT هو رمز مستقل، عديم الحالة يحمل المعلومات في صيغة منظمة وقابلة للقراءة.

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

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

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

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

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

التحقق من صحة رمز الوصول المبهم

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

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

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

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

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

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

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

الرموز المبهمة

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

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

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

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

JWTs

1. رمز الهوية:

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

// الحمولة المفككة لرمز الهوية
{
  "iss": "<https://auth.wiki>",
  "sub": "1234567890",
  "aud": "client_id",
  "exp": 1630368000,
  "name": "John Doe",
  "email": "[email protected]",
  "picture": "<https://example.com/johndoe.jpg>"
}

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

2. الوصول إلى موارد API (باستخدام رمز الوصول):

عندما يطلب العميل رمز وصول مع مؤشر الموارد (Resource indicator) محدد، يصدر خادم التفويض رمز وصول JWT مخصص للوصول إلى هذا المورد. يحتوي JWT على مطالبات يمكن لمزود المورد استخدامها لتفويض وصول العميل. على سبيل المثال:

// الحمولة المفككة لرمز الوصول JWT
{
  "iss": "<https://auth.wiki>",
  "sub": "1234567890",
  "aud": "<https://api.example.com>",
  "scope": "read write",
  "exp": 1630368000
}

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

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

انظر أيضا

• رمز الويب جيسون (JSON Web Token, JWT)