Logo Logo
GitHub Designed by Logto

ما هو رمز الوصول (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) المسؤوليات التالية:

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

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

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

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

انظر أيضا