مفكك ومشفّر JWT
تعتبر حالات فشل مصادقة JWT غير شفافة. لا يخبرك الرد 401 بأي شيء - لا يمكنك معرفة ما إذا كانت صلاحية الرمز المميز قد انتهت، أو ما إذا كانت مطالبة الجمهور خاطئة، أو الخوارزمية التي تم استخدامها، أو ما إذا تم التلاعب بالحمولة. تقوم معظم الأدوات عبر الإنترنت بفك التشفير فقط: لا يمكنها تشفير رمز مميز جديد، أو التحقق من التوقيع، أو إنشاء مفاتيح - والعديد منها يرسل الرموز المميزة الخاصة بك إلى خوادم خارجية.
تتعامل هذه الأداة مع جميع عمليات JWT الأربع في مكان واحد - فك التشفير والتشفير والتحقق وإنشاء المفاتيح - مع الدعم الكامل لخوارزميات HMAC (HS256 وHS384 وHS512) وRSA وRSA-PSS. قم بفحص مطالبات أي رمز مميز بدون مفتاح توقيع، وقم بتشفير الرموز المميزة الجديدة بحمولات مخصصة، والتحقق من التوقيعات مقابل الأسرار أو المفاتيح العامة، وإنشاء مفاتيح عشوائية آمنة تشفيريًا وجاهزة للإنتاج. يتم تشغيل كل شيء في متصفحك عبر Web Crypto API، ولا يترك أي رمز مميز أو مفتاح أو حمولة جهازك.
فك تشفير JWT
تشفير JWT
التحقق من توقيع JWT
JWT مولد المفتاح السري
ما هو جهاز فك ترميز JWT؟
وحدة فك ترميز JWT - والتي تسمى أيضًا محلل JWT، أو مصحح الأخطاء، أو العارض - هي أداة تقوم بتقسيم JSON Web Token إلى ثلاثة أجزاء: الرأس، والحمولة، والتوقيع، وتعرض كل منها على أنها JSON قابلة للقراءة. يقوم برنامج تشفير JWT بالعكس: فهو يأخذ رأسًا وحمولة ومفتاح توقيع، وينتج رمزًا مميزًا موقّعًا. JSON Web Token (JWT، يُنطق "jot") هو معيار مفتوح محدد بواسطة IETF في RFC 7519 لنقل المطالبات التي تم التحقق منها بين طرفين كسلسلة مدمجة وآمنة لعنوان URL.
تعد JWTs أساس المصادقة عديمة الجنسية في بنية الويب الحديثة. بعد تسجيل دخول المستخدم، يصدر خادم التفويض JWT موقعًا يحتوي على مطالبات تم التحقق منها - معرف المستخدم والدور ووقت انتهاء الصلاحية - ويعيدها إلى العميل. يقوم العميل بإرفاق هذا الرمز المميز بكل طلب لاحق لواجهة برمجة التطبيقات. يتحقق الخادم من التوقيع الرقمي دون الرجوع إلى مخزن الجلسة، مما يجعل النظام سريعًا وقابلاً للتطوير عبر الخدمات الصغيرة. في معظم الأنظمة، يتم إصدار رمز وصول قصير الأمد ورمز تحديث طويل الأمد معًا - يحمل رمز الوصول مطالبات JWT، بينما يتم استخدام رمز التحديث لطلب رمز جديد بعد انتهاء الصلاحية.
البروتوكولان الأكثر شيوعًا اللذين يعتمدان على JWTs هما OAuth 2.0 (الترخيص) وOpenID Connect (OIDC - الهوية والمصادقة). في كليهما، تحمل JWTs مطالبات موحدة محددة في RFC 7519. تُصدر كل من Google وMicrosoft وOkta وAuth0 رموز معرف OIDC كـ JWTs.
على عكس حزمة jwt-decode npm - التي تقوم بفك تشفير الرموز المميزة فقط - تقوم هذه الأداة أيضًا بتشفير وفك تشفير الرموز المميزة باستخدام أي خوارزمية HMAC أو RSA، والتحقق من التوقيعات، وإنشاء مفاتيح سرية، كل ذلك دون مغادرة المتصفح. تتضمن مكتبات JWT الرئيسية باللغات الأخرى PyJWT (Python)، وjjwt (Java)، وgolang-jwt (Go)، وjose (Rust) - استخدم هذه الأداة لاختبار الرموز المميزة التي تم إنشاؤها بواسطة أي منها.
كيفية استخدام هذه الأداة
فك تشفير JWT
- الصق JWT المشفر الذي تريد فحصه في حقل فك تشفير JWT.
- انقر فوق فك تشفير JWT.
- يظهر الرأس والحمولة بتنسيق JSON - يمكنك رؤية كل مطالبة اختار المُصدر تشفيرها في الرمز المميز. تحقق من المطالبات، والخوارزمية، والطابع الزمني لانتهاء الصلاحية، ومصدر البطاقة، وأي حقول مخصصة - لا يلزم وجود مفتاح توقيع.
تشفير JWT
- حدد خوارزمية التوقيع من القائمة المنسدلة , HS256 للتشفير باستخدام HMAC، أو RS256 أو PS256 للتشفير باستخدام RSA.
- أدخل مفتاحك السري (HMAC) أو المفتاح الخاص بتنسيق PEM (RSA / RSA-PSS).
- قم بتحرير Header JSON لتعيين alg و typ.
- قم بتحرير Payload JSON باستخدام مطالباتك - sub، أو iat، أو exp، أو الأدوار، أو أي حقول مخصصة.
- انقر فوق تشفير JWT لتشفير الرمز المميز وتوقيعه في خطوة واحدة.
التحقق من توقيع JWT
- الصق الرمز المميز في حقل التحقق من JWT.
- أدخل المفتاح السري (HMAC) أو المفتاح العام بتنسيق PEM (RSA / RSA-PSS). تتم قراءة الخوارزمية من رأس الرمز المميز تلقائيًا.
- انقر فوق التحقق من JWT. تقوم الأداة بإعادة تشغيل نفس العملية المستخدمة لترميز التوقيع ومقارنة النتيجة. صالح = تطابقات التوقيع. غير صالح = مفتاح خاطئ أو حمولة تم العبث بها.
إنشاء مفتاح سري
- حدد طول المفتاح , 256 بت لـ HS256، 384 بت لـ HS384، 512 بت لـ HS512.
- انقر فوق إنشاء سر.
- انسخ المفتاح وقم بتخزينه في متغير البيئة أو مدير الأسرار. لا تضع أبدًا أسرار التوقيع في الكود المصدري. للحصول على تنسيقات سرية إضافية، راجع مولد كلمات المرور الخاص بنا.
كيفية قراءة نتائجك
رأس فك التشفير
يكشف الرأس الذي تم فك تشفيره عن الإعدادات التي تم اختيارها عندما تم تشفير JWT. وهو كائن JSON يحتوي على حقلين قياسيين: alg (خوارزمية التوقيع , "HS256"، و"RS256"، و"PS256"، وما إلى ذلك) وtyp (دائمًا "JWT"). في حالة وجود حقل طفل (معرف المفتاح)، فإنه يحدد المفتاح الذي تم استخدامه لتوقيع الرمز المميز - المستخدم عندما ينشر خادم الترخيص مفاتيح عامة متعددة عبر نقطة نهاية JWKS (مجموعة مفاتيح ويب JSON) ويقوم بتدويرها بمرور الوقت.
الحمولة التي تم فك تشفيرها
تحتوي الحمولة على مطالبات الرمز المميز , بيانات حول الموضوع الذي تمت المصادقة عليه. تشتمل المطالبات القياسية المسجلة على sub (الموضوع - عادةً معرف مستخدم)، وISS (المصدر)، وaud (الجمهور)، وexp (انتهاء الصلاحية - طابع زمني Unix)، وiat (صدر في)، وnbf (ليس قبل)، وjti (معرف JWT). المطالبات المخصصة التي يضيفها تطبيقك - الأدوار، ومعرفات المؤسسة، ونطاقات الأذونات، وطبقة الاشتراك - تظهر هنا أيضًا.
الحمولة مشفرة بـ Base64URL، وليست مشفرة. يمكن لأي شخص لديه الرمز المميز فك تشفير الحمولة وقراءتها. لا تقم مطلقًا بتخزين كلمات المرور أو تفاصيل الدفع أو بطاقات الهوية الوطنية أو البيانات الشخصية الحساسة في حمولة JWT. بالنسبة للرموز المميزة التي يجب أن تحمل بيانات حساسة، استخدم JWE (RFC 7516) بدلاً من ذلك.
نتيجة التحقق من التوقيع
يقوم التحقق بإعادة حساب التوقيع الذي تم إنشاؤه عندما تم تشفير الرمز المميز، باستخدام الرأس والحمولة والمفتاح الذي تقدمه، ثم يقارنه بايتة بايت مع التوقيع المشفر في الرمز المميز. يؤكد "صالح" أن الرمز المميز تم توقيعه من قبل صاحب هذا المفتاح ولم يتم تغيير أي شيء. غير صالح يعني أن المفتاح خاطئ أو أنه تم العبث بالرمز المميز بعد التوقيع. لا يثبت فك التشفير وحده صحته أبدًا - تحقق دائمًا قبل التصرف بشأن أي مطالبة في الإنتاج.
هيكل رمز JWT
JWT عبارة عن ثلاث سلاسل مشفرة بـ Base64URL متصلة بنقاط: [header].[payload].[signature]. عندما تقوم بتشفير JWT، يتم ترميز كل قسم باستخدام Base64URL ويتم ربطه بالنقاط. عندما تقوم بفك تشفيره، يتم فصل كل قسم وعرضه كـ JSON. يحدد الرأس الخوارزمية. الحمولة تحمل المطالبات. التوقيع يثبت أنه لم يتم تغيير أي منهما.
[header].[payload].[signature]فيما يلي نموذج لرمز JWT يوضح كيفية تقسيم الأجزاء الثلاثة:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 ← الرأس
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ ← الحمولة
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ← التوقيعالصق نموذج JWT هذا في وحدة فك التشفير أعلاه لترى كل جزء تم فك تشفيره.
رأس
الرأس هو كائن JSON الذي تقوم بتشفيره في JWT كـ Base64URL. وهي تحدد نوع الرمز المميز ("JWT") والخوارزمية المستخدمة لإنشاء التوقيع - على سبيل المثال "HS256" (HMAC-SHA256) أو "RS256" (RSASSA-PKCS1-v1_5). تشتمل بعض الرموز المميزة على طفل (معرف المفتاح) لإخبار المستلم بالمفتاح العام الذي يجب استخدامه للتحقق عندما يقوم المُصدر بتدوير المفاتيح.
الحمولة
الحمولة عبارة عن كائن JSON يحتوي على المطالبات - مشفرة بـ Base64URL ولكنها غير مشفرة. يحدد RFC 7519 ثلاث فئات من المطالبات: المطالبات المسجلة (الأسماء القياسية مثل sub وiss وexp)، والمطالبات العامة (المسجلة في سجل مطالبات IANA JSON Web Token لمنع التصادمات)، والمطالبات الخاصة (الحقول المخصصة والخاصة بالتطبيق المتفق عليها بين جهة الإصدار والمستهلك).
التوقيع
التوقيع هو التوقيع الرقمي الذي يجعل JWT مقاومًا للتلاعب: فهو يربط الرأس والحمولة معًا ويثبت أنهما أتيا من مصدر موثوق. في خوارزميات HMAC تكون الصيغة HMACSHA256(base64url(header) + "." + base64url(payload), secret). في RSA يوقّع المفتاح الخاص، ويمكن لأي حامل للمفتاح العام المطابق التحقق. غيّر بايتًا واحدًا في الرأس أو الحمولة بعد التوقيع فيصبح التوقيع غير صالح، وهذا هو ضمان الأمان الأساسي في JWS (RFC 7515).
مطالبات JWT الشائعة
المطالبات المسجلة في JWT هي أسماء حقول موحدة محددة في RFC 7519. والأكثر أهمية هي exp (وقت انتهاء الصلاحية)، وsub (الموضوع - عادة معرف مستخدم)، وISS (المصدر)، وaud (الجمهور). كلها اختيارية ولكن يتم تنفيذها على نطاق واسع عبر أنظمة OAuth 2.0 وOIDC.
أسماء المطالبات المسجلة RFC 7519 - اختيارية ولكنها مدعومة على نطاق واسع عبر أنظمة OAuth 2.0 وOIDC:
المطالبة | الاسم الكامل | اكتب | قيمة المثال | الوصف |
|---|---|---|---|---|
| iss | المصدر | سلسلة/URI | "https://auth.example.com" | الخادم أو التطبيق الذي أصدر الرمز المميز |
| sub | الموضوع | سلسلة | "user_abc123" | من هو الرمز المميز - عادةً ما يكون معرف المستخدم |
| aud | الجمهور | سلسلة/صفيف | "api.example.com" | ما هي الخدمة (الخدمات) التي يجب أن تقبل هذا الرمز المميز؟ |
| exp | وقت انتهاء الصلاحية | تاريخ رقمي | 1716239022 | الطابع الزمني لنظام Unix , الرمز المميز غير صالح بعد هذه النقطة |
| nbf | ليس قبل | تاريخ رقمي | 1716235422 | يجب ألا يتم قبول الرمز المميز قبل هذا الطابع الزمني |
| iat | صدرت في | تاريخ رقمي | 1716235422 | عندما تم إنشاء الرمز المميز |
| jti | معرف JWT | سلسلة | "a1b2c3d4e5" | المعرف الفريد؛ تستخدم لمنع هجمات إعادة التشغيل |
| kid | معرف المفتاح | سلسلة | "2025-key-01" | يحدد المفتاح الذي قام بالتوقيع على الرمز المميز عند استخدام مفاتيح متعددة |
قيم NumericDate (exp، nbf، iat) هي ثوانٍ منذ عصر Unix , 00:00:00 بالتوقيت العالمي المنسق في 1 يناير 1970.
عندما تقوم بتشفير JWT، قم بإضافة مطالبات خاصة للبيانات الخاصة بالتطبيق: الأدوار، وطبقة الاشتراك، ومعرف المؤسسة، ونطاقات الأذونات. استخدم اسمًا بنمط URI مثل "https://yourapp.com/role" لتجنب تضاربات سجل IANA المستقبلية.
خوارزميات التوقيع المدعومة
تدعم هذه الأداة جميع متغيرات HMAC الثلاثة (HS256، HS384، HS512) وجميع متغيرات RSA / RSA-PSS الستة (RS256، RS384، RS512، PS256، PS384، PS512)، كما هو محدد في RFC 7518 (خوارزميات JSON Web). اختر HMAC لإعدادات الخدمة الفردية؛ اختر RSA للأنظمة الموزعة حيث تتحقق الخدمات من الرموز المميزة دون مشاركة مفتاح التوقيع.
خوارزمية | العائلة | نوع المفتاح | الحشو | الاستخدام الموصى به |
|---|---|---|---|---|
| HS256 | HMAC | سر مشترك | — | الافتراضي لمصادقة الخدمة الواحدة |
| HS384 | HMAC | سر مشترك | — | تجزئة أقوى لمتطلبات الامتثال |
| HS512 | HMAC | سر مشترك | — | أقصى قوة HMAC |
| RS256 | RSA | زوج المفاتيح | PKCS#1 v1.5 | مدعومة على نطاق واسع؛ استخدامها في الأنظمة الموزعة |
| RS384 | RSA | زوج المفاتيح | PKCS#1 v1.5 | تجزئة أطول لعائلة RS |
| RS512 | RSA | زوج المفاتيح | PKCS#1 v1.5 | أقصى قوة RS |
| PS256 | RSA-PSS | زوج المفاتيح | PSS (probabilistic) | يُفضل على RS256 للتطبيقات الجديدة |
| PS384 | RSA-PSS | زوج المفاتيح | PSS (probabilistic) | — |
| PS512 | RSA-PSS | زوج المفاتيح | PSS (probabilistic) | — |
HMAC (متماثل) , HS256، HS384، HS512
تستخدم خوارزميات HMAC (المحددة في RFC 2104) سرًا مشتركًا واحدًا لكل من التوقيع والتحقق. يجب أن يحمل كل من مصدر الرمز المميز وكل خدمة تتحقق من الرموز المميزة نفس السر.
- HS256: HMAC مع SHA-256. خوارزمية توقيع JWT الأكثر شيوعًا عبر النظام البيئي. الحد الأدنى الموصى به لطول السر: 256 بت (32 بايت).
- HS384: HMAC مع SHA-384. يُستخدم عندما تتطلب سياسة الأمان الخاصة بك حجم تجزئة أكبر.
- HS512: HMAC مع SHA-512. الحد الأقصى لقوة HMAC للبيئات عالية الامتثال.
RSA وRSA-PSS (غير متماثل) , RS256، RS384، RS512، PS256، PS384، PS512
تستخدم خوارزميات RSA زوجًا من المفاتيح. علامات المفتاح الخاص؛ يتحقق المفتاح العام. تحتاج خدمات التحقق فقط إلى المفتاح العام، والذي يمكن نشره بشكل مفتوح عبر نقطة نهاية JWKS.
- RS256 / RS384 / RS512: حشوة RSASSA-PKCS1-v1_5. مدعوم على نطاق واسع عبر جميع مكتبات ومنصات JWT.
- PS256 / PS384 / PS512: حشوة RSASSA-PSS. نظام التوقيع الاحتمالي بخصائص أمان أقوى من PKCS#1 v1.5. يوصى باستخدام متغيرات RS للتطبيقات الجديدة (راجع RFC 8017).
الحد الأدنى لحجم مفتاح RSA: 2048 بت؛ تفضل 4096 بت لمفاتيح التوقيع طويلة الأمد. استخدم HMAC عندما تقوم إحدى الخدمات بإصدار الرموز المميزة والتحقق منها. استخدم RSA أو RSA-PSS عندما تحتاج الخدمات المستقلة إلى التحقق من الرموز المميزة دون مشاركة سر التوقيع.
الثغرات الأمنية في JWT
JWT آمن عند تنفيذه بشكل صحيح. تظهر ثلاث نقاط ضعف بشكل متسق في عمليات تدقيق أمان واجهة برمجة التطبيقات: تجاوز alg:none، وارتباك الخوارزمية، وأسرار HMAC الضعيفة. كل ذلك ينبع من أخطاء التنفيذ، وليس عيوب في RFC 7519. يوفر RFC 8725 (JWT Best Current Practices, IETF) إرشادات التخفيف الرسمية.
هجوم alg:none
يقوم المهاجم بتعديل رأس الرمز المميز لتعيين "alg": "لا شيء"، ثم يزيل مقطع التوقيع. إذا قبل الخادم حقل alg من رأس الرمز المميز دون التحقق من الصحة، فإنه يتخطى التحقق من التوقيع بالكامل ويثق في الرمز المميز غير الموقع.
ضع دائمًا الخوارزميات المقبولة في قائمة سماح على جانب الخادم. لا تسمح أبدًا لرأس الرمز بتحديد الخوارزمية المستخدمة عند التشفير أو التحقق؛ استمدها من إعداداتك أنت. لدى كل مكتبة JWT رئيسية معامل algorithms صريح: مرّره. مثال: jwt.verify(token, secret, {'{'} algorithms: ['HS256'] {'}'})
ارتباك الخوارزمية (RS256 إلى HS256)
إذا كان الخادم يستخدم مفتاح RSA العام للتحقق من الرموز المميزة ولكنه لا يفرض alg، فيمكن للمهاجم تغيير الرأس إلى "alg": "HS256" وتوقيع الرمز المميز باستخدام المفتاح العام باعتباره سر HMAC. يتعامل الخادم بعد ذلك مع المفتاح العام باعتباره سر HMAC مشتركًا ويقبل الرمز المميز المزور.
فرض الخوارزمية المتوقعة من جانب الخادم. لا تستخدم أبدًا نفس المادة الأساسية لعائلات خوارزمية متعددة. قم بتكوين مكتبتك بشكل صريح لقبول RS256 أو PS256 فقط عند استخدام مفاتيح RSA.
أسرار HMAC ضعيفة
يمكن فرض رموز HS256 المميزة بأسرار قصيرة أو يمكن تخمينها دون الاتصال بالإنترنت. يمكن للمهاجم الذي يعترض رمزًا صالحًا تشغيل هجمات القاموس أو جدول قوس قزح ضد التوقيع دون أي تفاعل من الخادم. تتضمن الأسرار الضعيفة الشائعة أسماء "سرية" أو "كلمة مرور" أو تطبيقات.
استخدم المولد السري المدمج في هذه الصفحة لإنتاج مفتاح عشوائي مشفر بطول 256 بت (أو أطول). قم بتدوير السر فورًا عند أي تعرض مشتبه به.
التحقق من صحة المطالبة مفقود
يثبت التوقيع الصحيح أن الرمز المميز قد تم إصداره من قبل طرف معروف - ولا يثبت أن الرمز المميز مناسب للطلب الحالي. يسمح الفشل في التحقق من صحة exp (انتهاء الصلاحية) أو aud (جمهور) أو iss (مصدر) للمهاجمين بإعادة تشغيل الرموز المميزة منتهية الصلاحية، أو استخدام الرموز المميزة الصادرة لخدمة مختلفة، أو استخدام الرموز المميزة من مصدر غير موثوق به.
قم دائمًا بالتحقق من صحة EXP لرفض الرموز المميزة منتهية الصلاحية. قم بالتحقق من صحة التدقيق للتأكد من إصدار الرمز المميز لخدمتك المحددة. التحقق من صحة ISS لرفض الرموز المميزة من جهات الإصدار غير المتوقعة. تتعامل معظم مكتبات JWT مع عمليات التحقق هذه تلقائيًا إذا قمت بتمرير القيم المتوقعة في خيارات التحقق.
JWT مقابل المصادقة المستندة إلى الجلسة
JWTs عديمة الحالة - يتم تشفير جميع بيانات الجلسة في الرمز المميز. تقوم المصادقة المستندة إلى الجلسة بتخزين بيانات الجلسة من جانب الخادم وتمنح العميل معرف الجلسة فقط. يتم قياس JWTs بشكل أفضل أفقيًا؛ تدعم الجلسات الإلغاء الفوري.
ميزة | JWT (عديم الجنسية) | على أساس الجلسة (الحالة) |
|---|---|---|
| حيث يتم تخزين الحالة | داخل الرمز المميز (جانب العميل) | جانب الخادم (قاعدة البيانات أو ذاكرة التخزين المؤقت) |
| قابلية التوسع | أفقي - لا يوجد مخزن جلسة مشتركة | يتطلب مخزن جلسة مشتركة في إعدادات متعددة الخوادم |
| الإلغاء | لا يمكن الإلغاء قبل انتهاء الصلاحية بدون قائمة الرفض | فوري , احذف سجل الجلسة |
| حجم الرمز | أكبر (حوالي 200-500 بايت نموذجيًا) | معرف الجلسة الصغيرة (~ 20-40 بايت) |
| الاستخدام عبر النطاقات/واجهة برمجة التطبيقات (API). | سهل - رأس حامل قياسي | يتطلب تكوين مشاركة ملفات تعريف الارتباط |
| الخدمات المصغرة | مثالي - يتم التحقق من كل خدمة محليًا | يجب على كل خدمة الاستعلام عن مخزن الجلسة |
| البيانات الحساسة في الرمز المميز | غير مشفرة افتراضيًا (استخدم JWE) | لا تتعرض للعميل أبدًا |
| الأفضل ل | واجهات برمجة التطبيقات والخدمات الصغيرة وتطبيقات الهاتف المحمول والتسجيل الموحّد (SSO). | تطبيقات الويب التقليدية المقدمة من الخادم |
اختر JWT لواجهات برمجة التطبيقات الموزعة والخدمات الصغيرة وتطبيقات الهاتف المحمول والدخول الموحد (SSO) وأي بنية تحتاج فيها خدمات مستقلة متعددة إلى التحقق من الرموز المميزة دون مشاركة مخزن الجلسة.
اختر جلسات للتطبيقات التي تتطلب الإلغاء الفوري للرمز المميز (الأنظمة المالية، أدوات الإدارة)، أو تطبيقات الويب التقليدية التي يعرضها الخادم، أو الأنظمة التي يمثل فيها حجم الرمز المميز قيدًا.
الخصوصية والأمن
- يعمل بالكامل في المتصفح الخاص بك.تتم جميع عمليات التشفير وفك التشفير والتحقق وإنشاء المفاتيح من جانب العميل عبر Web Crypto API وJavaScript. سواء قمت بتشفير رمز مميز جديد أو فك تشفير رمز موجود، فلن يتم إرسال أي بيانات إلى أي خادم. مثل جميع الأدوات الموجودة لدينا مجموعة أدوات الأمن ، هذه الأداة من جانب العميل بالكامل.
- لا يتم تخزين أو تسجيل أي شيء.لا يتم الاحتفاظ بسجل لأي رمز مميز أو سر أو حمولة تقوم بإدخالها.
- المشفرة غير مشفرة.حمولات JWT (JWS) مشفرة بـ Base64URL - ويمكن لأي شخص لديه الرمز المميز قراءتها. التوقيع الرقمي يجعل الحمولة غير قابلة للتلاعب ولكنها ليست خاصة. بالنسبة للرموز المميزة التي يجب أن تحمل بيانات حساسة، استخدم JWE (JSON Web Encryption, RFC 7516) بدلاً من ذلك. تتعامل هذه الأداة مع JWS فقط.
- فك التشفير ليس المصادقة.قراءة محتويات الرمز المميز لا تثبت أن الرمز صالح أو جدير بالثقة. تحقق دائمًا من التوقيع - وتحقق من صحة EXP وAUD وISS - قبل التصرف بشأن أي مطالبة في الإنتاج.
- تعامل مع مفاتيح التوقيع مثل كلمات المرور.استخدم المولد هنا للحصول على مفتاح عشوائي مشفر بالطول الصحيح. قم بتخزينه في متغير بيئة أو مدير أسرار مخصص. قم بتدويرها إذا كنت تشك في التعرض. لا تلزمه أبدًا بالتحكم في الإصدار.
الأسئلة المتداولة
أسئلة مكررة