استجابة مصادقة وهمية

تعمل في المتصفح المحاكاة

أنتج استجابات مصادقة واقعية (استجابة رمز OAuth 2.0، وتسجيل دخول بجلسة، وid_token في OIDC مع JWT غير موقّع قابل لفك الترميز) إضافةً إلى متغيرات الفشل لحالات انتهاء الصلاحية وبيانات الاعتماد غير الصالحة والحسابات المقفلة.

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

كيف يعمل توثيق واجهات API بالرموز؟

تُوثّق معظم الواجهات كل طلب ببيانات اعتماد تُرسَل في ترويسة: رمز bearer (غالباً JWT صادر عن تدفق OAuth 2.0)، أو مفتاح API، أو بيانات Basic عبر TLS. يتحقق الخادم منها في كل نداء — التوقيع والانتهاء والجمهور والنطاقات — ويجيب بـ 401 عند غيابها أو بطلانها وبـ 403 عندما تكون صالحة لكنها غير مصرَّح لها. اختبار التوثيق يعني تجربة كل هذه المسارات لا المسار السعيد فقط.

ملاحظة أمنية: خلل التوثيق وخلل التفويض على مستوى الكائن يتصدران قائمة OWASP لأمن الواجهات. اختبر أن الرمز المنتهي أو المعدَّل أو الخاص بمستخدم آخر يُرفض، وأن كل معرّف كائن يُفحص مقابل المستدعي — لا نقطة النهاية فقط.

اقرأ الدليل: ما هو JWT؟ شرح رموز JSON Web Token

كيفية استخدام استجابة مصادقة وهمية

  1. أدخل اختيارياً البريد الإلكتروني للمستخدم والنطاقات (scopes) والأدوار.
  2. اختر الشكل والنتيجة (نجاح أو إحدى حالات الفشل).
  3. ولّد الاستجابة واستخدم الجسم في محاكاة المصادقة في الواجهة الأمامية.

مزايا استجابة مصادقة وهمية

  • أشكال OAuth 2.0 وOpenID Connect وزوج JWT وملف تعريف ارتباط الجلسة ومفتاح API
  • رموز JWT غير موقّعة قابلة لفك الترميز (alg "none") أو توقيعات HS256 وهمية مع مطالبات (claims) واقعية
  • متغيرات الفشل: بيانات اعتماد غير صالحة، ورمز منتهي الصلاحية، وحساب مقفل، وبريد إلكتروني غير موثَّق، والمصادقة متعددة العوامل (MFA) مطلوبة
  • ترويسات صحيحة: Cache-Control: no-store وWWW-Authenticate وSet-Cookie وRetry-After
  • عرض المطالبات بعد فك ترميزها إلى جانب الاستجابة

مثال على استجابة مصادقة وهمية

استجابة رمز OAuth 2.0

الإدخال:

Shape: OAuth 2.0, outcome: success, expires in 3600

النتيجة:

{
  "access_token": "eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiI…",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "rt_9kM2…",
  "scope": "openid profile email offline_access"
}

الأسئلة الشائعة حول استجابة مصادقة وهمية

ما الأشكال التي تُولَّد؟

استجابات رموز OAuth 2.0، واستجابات OpenID Connect مع id_token، وأزواج JWT للوصول/التحديث مع كائن مستخدم، وتسجيلات دخول بجلسة مع ترويسة Set-Cookie ورمز CSRF، وإصدار مفاتيح API.

هل رموز JWT حقيقية؟

يمكن فك ترميزها بأي أداة JWT، وتحتوي على مطالبات واقعية (iss وsub وaud وiat وexp وscope وroles)، لكنها غير مؤمَّنة (alg "none") أو تحمل توقيعاً وهمياً عشوائياً. ويجب ألّا يقبلها أي خادم أبداً.

ما حالات الفشل المتوفرة؟

بيانات اعتماد/منحة (grant) غير صالحة، ورمز منتهي الصلاحية (401 مع WWW-Authenticate)، وحساب مقفل (423 مع Retry-After)، وبريد إلكتروني غير موثَّق (403)، والمصادقة متعددة العوامل مطلوبة.

هل يمكنني تحديد المستخدم والنطاقات؟

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

ملاحظات تقنية

يُبنى رمز الوصول وid_token بصيغة header.payload. مع توقيع فارغ، وهو ما يعرّفه RFC 7519 بأنه JWT غير مؤمَّن، أو مع مقطع توقيع عشوائي عند طلب ترويسة HS256 وهمية. وتحمل هذه الرموز iss وsub وaud وiat وexp وnbf وjti وscope وroles حتى يمكن اختبار منطق انتهاء الصلاحية في جانب العميل، لكن لا يمكن لأي خادم حقيقي التحقق منها.

المراجع