كيف يعمل توثيق واجهات API بالرموز؟
تُوثّق معظم الواجهات كل طلب ببيانات اعتماد تُرسَل في ترويسة: رمز bearer (غالباً JWT صادر عن تدفق OAuth 2.0)، أو مفتاح API، أو بيانات Basic عبر TLS. يتحقق الخادم منها في كل نداء — التوقيع والانتهاء والجمهور والنطاقات — ويجيب بـ 401 عند غيابها أو بطلانها وبـ 403 عندما تكون صالحة لكنها غير مصرَّح لها. اختبار التوثيق يعني تجربة كل هذه المسارات لا المسار السعيد فقط.
ملاحظة أمنية: خلل التوثيق وخلل التفويض على مستوى الكائن يتصدران قائمة OWASP لأمن الواجهات. اختبر أن الرمز المنتهي أو المعدَّل أو الخاص بمستخدم آخر يُرفض، وأن كل معرّف كائن يُفحص مقابل المستدعي — لا نقطة النهاية فقط.
اقرأ الدليل: ما هو JWT؟ شرح رموز JSON Web Token
كيفية استخدام مفكّك ترميز رموز OAuth
- انسخ access_token أو id_token من استجابة OAuth لديك (أو من ترويسة Authorization).
- الصقه واقرأ ملخص الرمز: النوع والمزوّد والجهة المُصدِرة والجمهور والصلاحية.
- راجع جدول النطاقات للتأكد من الصلاحيات الممنوحة فعلياً.
- استخدم جدول المطالبات لفهم الحقول الخاصة بكل مزوّد.
مزايا مفكّك ترميز رموز OAuth
- يميّز رموز الهوية ورموز الوصول ورموز تسجيل الخروج وإثباتات DPoP
- يكتشف رموز Azure AD (Entra ID) وAuth0 وKeycloak وGoogle وOkta وCognito وFirebase وApple
- يشرح قيم scope/scp والمطالبات الخاصة بكل مزوّد (tid وoid وazp وrealm_access وgty وhd…)
- يعرض الجهة المُصدِرة والجمهور والعميل والموضوع (subject) ووقت المصادقة وطرقها
- ملخص الصلاحية مع مدة العمر؛ ويذكّرك بأن رمز الهوية لا يجوز إرساله إلى واجهة API بوصفه رمز حامل (bearer)
- جدول كامل بالمطالبات إلى جانب JSON الخام للترويسة والحمولة
مثال على مفكّك ترميز رموز OAuth
رمز وصول Azure AD الإصدار 2.0
الإدخال:
{"aud":"api://orders","iss":"https://login.microsoftonline.com/<tenant>/v2.0","scp":"Orders.Read Orders.Write openid profile","tid":"<tenant>","oid":"<object-id>","azp":"<client-id>","ver":"2.0", …}النتيجة:
Token type: Access token · Provider: Azure AD (Microsoft Entra ID)
Audience: api://orders · Client: <client-id> · Tenant: <tenant>
Scopes: Orders.Read, Orders.Write, openid (requests an ID token), profile (basic profile claims)الأسئلة الشائعة حول مفكّك ترميز رموز OAuth
ما الفرق بين رمز الهوية ورمز الوصول؟
يخبر رمز الهوية (OpenID Connect) تطبيق العميل بهوية المستخدم وهو مخصّص للعميل وحده. أما رمز الوصول فيفوّض استدعاءات واجهة API (خادم المورد). تخمّن الأداة النوع من typ وnonce وscope والمطالبات الخاصة بالمزوّد.
رمز الوصول الخاص بي ليس JWT — هل يمكن فكّ ترميزه؟
لا. يُصدر كثير من المزوّدين (GitHub وبعض إعدادات Google وAuth0) رموزاً مبهمة ليست سوى سلاسل عشوائية. ولا يمكن تفسيرها إلا من قِبل الجهة المُصدِرة عبر نقطة نهاية لفحص الرموز (token introspection).
كيف يُكتشف المزوّد؟
من عنوان URL للجهة المُصدِرة والمطالبات المميِّزة: tid/oid لـ Azure AD (Entra ID)، وrealm_access لـ Keycloak، وgty/permissions لـ Auth0، وhd لـ Google، وuid/cid لـ Okta، وtoken_use لـ Cognito، وهكذا.
ما معنى scope وscp؟
كلاهما يسرد الصلاحيات الممنوحة للرمز. scope هو الصيغة القياسية المفصولة بمسافات (RFC 6749/8693)؛ أما scp فتستخدمه Azure AD وOkta. ويُشرح كل نطاق حيثما كان معناه معروفاً.
ملاحظات تقنية
لا يفرض OAuth 2.0 صيغة محددة للرموز، لكن معظم المزوّدين يُصدرون رموز وصول JWT وفق RFC 9068 (typ بقيمة «at+jwt» وclient_id وscope) ورموز هوية OIDC (nonce وat_hash وauth_time وamr). يعتمد اكتشاف المزوّد على مضيف الجهة المُصدِرة والمطالبات المميِّزة؛ وعندما لا يتطابق شيء، يُفكّ ترميز الرمز بالكامل مع ذلك.
المراجع
- RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usageكيف يُرسَل رمز bearer (Authorization: Bearer …) واستجابات الخطأ التي يعيدها خادم الموارد.
- RFC 6749: The OAuth 2.0 Authorization Frameworkأدوار OAuth 2.0 وأنواع المنح ونقاط نهاية الرموز التي تُصدر رموز الوصول والتحديث.
- RFC 9700: Best Current Practice for OAuth 2.0 Securityإرشادات الأمان الحالية لـ OAuth 2.0: استخدام PKCE للعملاء العامين ومطابقة عناوين إعادة التوجيه بدقة وتقييد الرموز بالمرسل.
- RFC 7519: JSON Web Token (JWT)يعرّف صيغة JWT — الترويسة والحمولة والتوقيع — والمطالبات المسجّلة iss وsub وaud وexp وnbf وiat وjti.