رمز الوصول (Access token)

ما هو رمز الوصول (Access token)؟

رمز الوصول (Access token) هو اعتماد، عادةً ما يكون سلسلة من الأحرف، يستخدم للوصول إلى الموارد المحمية. في سياق OAuth 2.0 و OpenID Connect (OIDC)، قد تصدر خوادم الترخيص (authorization servers) رموز الوصول للعملاء (التطبيقات) بعد المصادقة (authentication) والترخيص بنجاح.

على الرغم من أن المذكرات الفنية لـ OAuth 2.0 و OIDC لا تحدد تفاصيل تنفيذ رموز الوصول، فهناك نوعان شائعان من رموز الوصول المستخدمة في الواقع:

• توكن غير شفاف (Opaque token) : سلسلة عشوائية لا معنى لها (“غير شفافة”) للعميل. يقدم العميل الرمز إلى خادم الموارد، الذي يقوم بالتحقق من صحة الرمز مع خادم الترخيص (authorization server).
• رمز الويب جيسون (JSON Web Token, JWT) : رمز مستقل يحتوي على مطالبات (claims) (مثل معرف المستخدم، وقت انتهاء الصلاحية) مع توقيع رقمي. يمكن لخادم الموارد التحقق من صحة الرمز دون تقديم طلب إضافي إلى خادم الترخيص (authorization server).

كيف يعمل رمز الوصول (Access token)؟

وفقًا لنوع رمز الوصول (access token)، قد يختلف تدفق استخدام رمز الوصول.

إليك مثال مبسط لاستخدام رمز وصول غير شفاف (opaque token):

إليك مثال مبسط لاستخدام JWT:

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

• يجب على خادم الموارد تقديم طلب إضافي إلى خادم الترخيص (authorization server) للتحقق من صحة الرمز غير الشفاف (opaque token) في كل مرة يستلم فيها الرمز.
• يمكن لخادم الموارد التحقق من صحة JWT دون تقديم طلب إضافي إلى خادم الترخيص (authorization server) لأن الرمز يحتوي على جميع المعلومات الضرورية ويمكن لخادم الموارد تخزين المفتاح العام من مجموعة مفاتيح خادم الترخيص JSON Web Key Set (JWKS).

رموز الوصول (Access tokens) عادة ما تكون قصيرة الأجل ولها وقت انتهاء صلاحية (مثل ساعة واحدة). يجب على العملاء طلب رمز وصول جديد عند انتهاء صلاحية الرمز الحالي.

أي نوع من الرموز (token) يجب أن أستخدم؟

الاختيار بين رمز غير شفاف (opaque token) و JWT يعتمد على حالة الاستخدام ومتطلبات الأمان للتطبيق. إليك مقارنة بين النوعين من الرموز:

	رمز غير شفاف (Opaque Token)	JWT
الشكل	سلسلة عشوائية	كائنات JSON مستقلة
الأداء	يتطلب طلب إضافي	تحقق أسرع
مستقل	لا	نعم
حجم الرمز	أصغر	أكبر
الإلغاء	فوري	يتطلب انتهاء صلاحية الرمز أو تفاعل خادم الترخيص
قابلية التمديد	محدود	مطالبات مخصصة
بدون دولة	لا	نعم
الأمان	يتطلب تحقق من صحة الرمز	يتطلب تحقق من صحة التوقيع
معياري	لا	نعم (RFC 7519)

لمزيد من المعلومات حول اختيار بين النوعين من الرموز، راجع Opaque token vs JWT .

أدوار خادم الترخيص (authorization server) وخادم الموارد (resource server)

في معظم الحالات، يتحمل خادم التفويض (Authorization server) المسؤوليات التالية:

• إصدار رموز الوصول للعملاء بعد المصادقة (authentication) والترخيص بنجاح. قد يقوم خادم الترخيص بتقليل النطاقات (scopes) أو رفض طلب الرمز بناءً على سياسات التحكم في الوصول (access control) (مثل موافقة المستخدم، التحكم في الوصول بناءً على الأدوار (Role-based access control, RBAC) ، التحكم في الوصول المستند إلى السمة (Attribute-based Access Control, ABAC) ).
• التحقق مما إذا كان رمز الوصول قد تم إصداره بواسطة خادم الترخيص ولم ينته صلاحيته أو يُلغى ( تفتيش الرمز المميز (Token introspection) ).
• تقديم المعلومات عن الرمز (مثل النطاقات، وقت انتهاء الصلاحية) عبر فحص الرمز أو نقطة نهاية معلومات المستخدم (Userinfo endpoint) .

يمكنك ملاحظة أن خادم الترخيص لا يفسر معنى رمز الوصول. على سبيل المثال، قد يحتوي رمز الوصول (access token) على نطاق read:orders، لكن خادم الترخيص لا يعرف ماذا يعني النطاق. يتحمل خادم الموارد مسؤولية تفسير رمز الوصول وفرض التحكم في الوصول (Access control) بناءً على نطاقات الرمز. هذا يعني أن خادم الموارد (Resource server) عادة ما يتحمل المسؤوليات التالية:

• التحقق من صحة المطالبات (claims) في رمز الوصول (مثل وقت انتهاء الصلاحية، مؤشر المورد، النطاقات).
• فرض التحكم في الوصول (access control) بناءً على مطالبات (claims) الرمز (غالبًا النطاقات).
• تقديم الموارد المحمية إذا كان رمز الوصول صالحًا.

دورة حياة رمز الوصول (Access token)

تشمل دورة حياة رمز الوصول عادة المراحل التالية:

انظر أيضا

• توكن غير شفاف (Opaque token)
• رمز الويب جيسون (JSON Web Token, JWT)
• تفتيش الرمز المميز (Token introspection)
• نقطة نهاية معلومات المستخدم (Userinfo endpoint)
• التحكم في الوصول (Access control)