لا تحب الإعلانات؟ يذهب خالية من الإعلانات اليوم 

مُولد مُختبر رمز PKCE ومحرّر التحدي

مطورحماية

إعلان · حذف؟

مدخل

تكوين PKCE

طول المُعتمَد: 64 تطلب RFC 7636 43 إلى 128 حرفًا. القيم الطويلة تزيد من التشتت.

طريقة التحدي

يُطلب S256 من وثيقة OAuth 2.1 ويُدعم من قبل كل مزود حديث.

مُجموعة الحروف للـ verifier

كلا الخيارين يُنتجان مُعتمَدات متوافقة مع RFC 7636. اختر ما يُتوقع من بيئة العميل.

انتاج

جانب العميل

إعلان · حذف؟

مرشد

مُولد مُختبر رمز PKCE ومحرّر التحدي

أنشئ قيمًا متوافقة مع RFC 7636 للـ PKCE مباشرة في متصفحك. اختر طول verifer (من 43 إلى 128 حرفًا)، وستُنتج قيمة عشوائية مشفّرة بطرق مُعتمدة. code_verifier مع التحدي المُقابل المُشفّر بـ SHA-256 code_challenge بشكل base64url، جاهزة للإدخال في طلب تأكيد OAuth 2.0 أو 2.1. مفيدة للتطبيقات المبنية على واجهة المستخدم (SPAs)، التطبيقات المحمولة، أدوات الحوسبة المتنقلة، وجميع من يُختبر تدفق التأكيد باستخدام رمز التحقق مع PKCE ضد مزودي مثل Auth0، Okta، Microsoft Entra، Google، GitHub، وKeycloak.

كيفية استخدام

اسحب طول Verifier مُستخدم مُتحرك — أي قيمة بين 43 و128 تُعتبر مناسبة؛ القيم الطويلة تزيد من التشتت.
اختر طريقة التحديأبقِها مُفعَّلة S256 إلا إذا طلب مزودك ذلك بشكل صريح plain.
اختر مُجموعة الحروف للـ verifierكلا الخيارين متوافقان مع المعيار؛ يتطابق أصل الحروف base64url مع ما يُنتجها معظم مكتبات العميل.
انقر إنتاجيظهر الـ verifier، التحدي، وطريقة التحدي فورًا، مع تفصيل خطوة بخطوة للتحويل من SHA-256 إلى base64url.
انسخ code_challenge + code_challenge_method إلى /authorize الاتجاه، احفظ code_verifier في sessionStorage، وقم بتشغيله على /token لإكمال التبادل.

خصائص

مُنَسَّق بطرق مُستندة إلى الحاسوب – يستخدم crypto.getRandomValues() باستخدام طريقة رفض العينات لضمان عدم وجود تحيز عند استخدام 66 حرفًا من الحروف المسموحة.
مُنَسَّق SHA-256 – يتم حساب التحدي من خلال متصفح SubtleCrypto.digest('SHA-256')، لذا تتطابق القيم مع ما سيُنتجها خادم التأكيد.
طريقة S256 وطريقة plain – تدعم كلا القيم من RFC 7636، مع code_challenge_method التي تُستخدم بشكل افتراضي وفق OAuth 2.1. S256 – اعرض الـ verifier الخام، وملف 32 بيت من تشفير SHA-256، والتحدي النهائي base64url لكي تتمكن من مراجعة كل تحوّل.
خطوة بخطوة تفكيك خيارات مُعتمدة للحروف
– اختر مجموعة كاملة من الحروف المسموحة وفق RFC 7636 (A–Z، a–z، 0–9، ) أو الحروف المحدودة للـ base64url التي تُستخدم كافتراض في معظم المكتبات. -, ., _, ~مقياس الطول من 43 إلى 128
– تبقى ضمن المعيار دون الحاجة إلى تدبير أرقام مخفية. مُضمن في كل حقل إخراج لكي تتمكن من لصقها مباشرة في Postman أو curl أو في كود العميل.
نسخ بنقرة واحدة – لا يتم إرسال أي شيء إلى خادم. لا يترك الـ verifier متصفحك.
100% من جانب العميل ما هو PKCE وما السبب في احتجار OAuth له؟

 التعليمات

مفتاح التأكيد للتبادل (PKCE، RFC 7636) هو توسعة لـ OAuth 2.0 تحمي تدفق الرمز من التدخل. يختار العميل سرًّا

، ويُنتج code_verifierمنه، ويُرسل فقط التحدي في طلب التأكيد. عند إعادة استخدام العميل للرمز في نقطة التسليم، يرسل الـ verifier الأصلي؛ يُحسب الخادم له ويُقارن مع التحدي المحفوظ. حتى لو اُدخل الرمز من قبل مهاجم، لا يمكنه تبادله دون الـ verifier، الذي لا يترك العميل الموثوق. code_challenge أصبحت ميزة PKCE إلزامية في OAuth 2.1 لكل العميلين، سواء كان علنيًا أو مُعتمدًا.
ما الطول المناسب لـ code_verifier وما السبب؟

تطلب RFC 7636 أن يكون الـ verifier بين 43 و128 حرفًا من مجموعة الحروف المسموحة. توجد حد أدنى لأن 43 حرفًا من base64url تُمثل 32 بيتًا عشوائيًا (256 بت) – وهو الحد الأدنى للحماية من التسريب. القيم الطويلة تزيد من التشتت ولكن لا تُقدّم ميزة أمنية حقيقية بعد 256 بت. تستخدم معظم المراجعات 43، 64، أو 128. اختر الطرف الطويل إذا أردت حماية متعددة الطبقات، ولكن انتبه أن بعض الخوادم القديمة قد ترفض أي قيمة تزيد عن 128 لأنها تُطبق المعيار بدقة.
ما الفرق بين طريقة التحدي S256 وطريقة plain؟

تُرسل الأكواد إلى S256 التحدي هو تشفير SHA-256 للـ verifier، مُشفَّر بـ base64url؛ مع plain التحدي هو الـ verifier نفسه. الطريقة plain لا تُقدّم حماية حقيقية إذا تم انتهاك طلب التأكيد — أي مهاجم يرى التحدي يمتلك الـ verifier. يسمح RFC 7636 فقط plain لأطراف لا تستطيع حساب SHA-256، وتم حظرها تمامًا في OAuth 2.1. ترفض مزودات الهوية الحديثة مثل Auth0، Okta، Google، وMicrosoft Entra plain بشكل صريح، لذا استخدم دائمًا S256 إلا إذا كنت تُختبر تطبيق محدود أو مدمج.
ما هو base64url وما الفرق بينه وbase64؟

base64url هو نسخة آمنة للـ base64 مُعرّفة في RFC 4648 §5. يُستبدل + المسائل الشائعة التي يجب مراقبتها - و / المسائل الشائعة التي يجب مراقبتها _ لأن النص المُشفَّر آمن للاستخدام في معلمات الاستعلام، أو قسم JWT، أو مكونات المسار دون الحاجة إلى تشفير إضافي. يتم إزالة التعبئة = التي تُضاف لأن طولها مُفترض من السياق. تستخدم معظم معايير الحوسبة الحديثة مثل PKCE، JWT، JWE، JWS، ونماذج الحوسبة الحديثة للويب base64url لأسباب مماثلة.