مشفر JWT

أنشئ وقّع JSON Web Tokens باستخدام HS256 و HS384 و HS512

الرأس

يعمل محليًا · آمن للصق الأسرار

البيانات

يعمل محليًا · آمن للصق الأسرار

المفتاح السري

يعمل محليًا · آمن للصق الأسرار

JWT المُشفّر

Output will appear here…

مفتاحك السري لا يترك متصفحك. يتم إجراء جميع التوقيعات على جانب العميل.

جرب أيضاً:فك تشفير JWT

ما هو تشفير JWT؟

تشفير JWT هو عملية إنشاء JSON Web Token — سلسلة نصية آمنة للعنوان URL تحمل مجموعة من الدعاوى موقعة بمفتاح تشفيري. والنتيجة هي رمز مكون من ثلاثة أجزاء (رأس. حمولة. توقيع) معرّف في RFC 7519 يمكن للخوادم التحقق منه دون الحفاظ على حالة الجلسة.

يُعلن الـ header عن خوارزمية التوقيع (مثلًا HS256) ونوع الرمز. يحتوي الـ payload على المطالبات — أزواج مفتاح-قيمة كموضوع الرمز (sub) ووقت الانتهاء (exp) وأي بيانات مخصصة يحتاجها تطبيقك. يُسلسَل كلا الجزأين بصيغة JSON ثم يُشفَّران بـ base64url. تُحسَب التوقيعة فوق الـ header والـ payload المُشفَّرَين باستخدام مفتاح سري، مما يربط الأجزاء الثلاثة معًا.

خلافًا لملفات تعريف ارتباط الجلسة، تكتفي JWT بذاتها: لا يحتاج المُحقِّق إلى الاستعلام عن قاعدة البيانات أو استدعاء خدمة خارجية. هذا ما جعل المصادقة المبنية على JWT شائعةً في REST API والخدمات المصغَّرة وتطبيقات الصفحة الواحدة، حيث يُقلِّل التفويض عديم الحالة من زمن الاستجابة ويُبسِّط التوسع الأفقي.

لماذا تستخدم مُرمِّز JWT؟

إنشاء JWT يدويًا يتطلب تشفير base64url وتسلسل JSON وحساب HMAC. تتولى هذه الأداة الخطوات الثلاث فورًا حتى تتفرغ للتركيز على ضبط المطالبات.

توليد رمز فوري
عدِّل الـ header والـ payload والمفتاح السري — يتحدث JWT الموقَّع في الوقت الفعلي. بدون خطوة بناء، بدون تثبيت مكتبة، بدون كود نمطي.
🔒
خوارزميات HMAC متعددة
بدِّل بين HS256 وHS384 وHS512 بنقرة واحدة. يتحدث الـ header تلقائيًا وتُعاد حساب التوقيعة فورًا.
🛡️
معالجة تُقدِّم الخصوصية أولًا
يتم كل التوقيع في متصفحك باستخدام Web Crypto API. مفتاحك السري وبيانات الـ payload لا تغادران جهازك — لا خادم، لا سجلات، لا مخاطر.
📋
مساعدات إضافة المطالبات بنقرة واحدة
أضف طوابع iat وexp+1h أو exp+24h بزر واحد. لا حاجة لحساب طوابع Unix الزمنية يدويًا أو البحث عن وقت epoch الحالي.

حالات استخدام مُرمِّز JWT

اختبار مصادقة الواجهة الأمامية
أنشئ رموزًا بمطالبات محددة وأوقات انتهاء صلاحية لاختبار تدفقات تسجيل الدخول ومنطق تحديث الرمز وحراسة المسارات المحمية دون تشغيل خادم مصادقة خلفي.
تطوير API الخلفي
أنشئ رموز اختبار بمطالبات sub وaud وscope مخصصة لاختبار برمجيات التفويض الوسيطة، والتحكم في الوصول القائم على الأدوار، وفحوصات الأذونات أثناء التطوير المحلي.
أنظمة DevOps وCI/CD
أنشئ رموز خدمة قصيرة الأمد لسكريبتات النشر واختبارات التكامل أو الاتصال بين الخدمات، حيث يُضيف تدفق OAuth الكامل تعقيدًا غير ضروري.
اختبار الجودة والاختبار اليدوي
أنشئ رموزًا بمطالبات حالات حافة — رموز منتهية الصلاحية، حقول مفقودة، جمهور خاطئ — للتحقق من أن API يُعيد استجابات HTTP 401 أو 403 الصحيحة.
التدقيق الأمني
أنشئ رموزًا موقَّعة بخوارزميات وأطوال مفاتيح مختلفة للتحقق من أن منطق التحقق لديك يرفض التوقيعات الضعيفة أو غير المتطابقة بشكل صحيح.
التعلم والنماذج الأولية
يمكن للطلاب والمطوِّرين الجدد على JWT تجربة حقول الـ header وهياكل المطالبات وخوارزميات التوقيع لفهم كيفية عمل كل جزء من الرمز.

HS256 مقابل HS384 مقابل HS512: مقارنة خوارزميات HMAC

تستخدم الخوارزميات الثلاث HMAC (رمز مصادقة الرسائل القائم على الدالة الهاشية) مع سر مشترك. الفرق هو دالة الهاش الأساسية التي تؤثر على طول التوقيعة وهامش الأمان. لمعظم التطبيقات، يوفر HS256 أمانًا كافيًا. اختر HS384 أو HS512 عندما تستلزم متطلبات الامتثال (مثل FIPS-140) هاشًا أقوى أو حين تحمل رموزك قرارات تفويض عالية القيمة.

الخوارزميةالهاشالتوقيعةالسرعةالاستخدام النموذجي
HS256SHA-25632 BFastestGeneral purpose, default for most libraries
HS384SHA-38448 BFastHigher security margin, FIPS-140 compliant
HS512SHA-51264 BFastMaximum HMAC security, large payloads

مرجع مطالبات JWT القياسية

يُعرِّف RFC 7519 سبعة مطالبات مسجَّلة. لا شيء منها إلزامي، لكن استخدامها الصحيح يُحسِّن التشغيل البيني والأمان. مطالبة exp مهمة بشكل خاص — الرموز الخالية من وقت انتهاء الصلاحية صالحة إلى أجل غير مسمى إذا لم يُدَر السر.

المطالبةالاسمالوصفمثال
issIssuerWho issued the token"auth.example.com"
subSubjectWho the token represents"user-123"
audAudienceIntended recipient service"api.example.com"
expExpirationUnix timestamp — token invalid after this time1717203600
nbfNot BeforeUnix timestamp — token invalid before this time1717200000
iatIssued AtUnix timestamp when the token was created1717200000
jtiJWT IDUnique token identifier for revocation tracking"a1b2c3d4"

ترميز JWT في الكود

تُظهر هذه الأمثلة كيفية إنشاء JWT وتوقيعها برمجيًا. كل مقتطف ينتج رمزًا صالحًا موقَّعًا بـ HS256. في أنظمة الإنتاج، احرص دائمًا على تعيين مطالبة exp واستخدام سر عشوائي تشفيري بطول 256 بت على الأقل.

JavaScript (Web Crypto API)
async function signJWT(payload, secret, alg = 'HS256') {
  const header = { alg, typ: 'JWT' }
  const enc = new TextEncoder()

  // Base64url encode header and payload
  const b64url = (obj) =>
    btoa(JSON.stringify(obj)).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

  const h = b64url(header)
  const p = b64url(payload)

  // Sign with HMAC-SHA256
  const key = await crypto.subtle.importKey(
    'raw', enc.encode(secret),
    { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']
  )
  const sig = await crypto.subtle.sign('HMAC', key, enc.encode(`${h}.${p}`))
  const s = btoa(String.fromCharCode(...new Uint8Array(sig)))
    .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

  return `${h}.${p}.${s}`
}

// Usage
const token = await signJWT(
  { sub: 'user-123', name: 'Alice', iat: Math.floor(Date.now() / 1000) },
  'your-256-bit-secret'
)
// → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi..."
Python (PyJWT)
import jwt
import time

payload = {
    "sub": "user-123",
    "name": "Alice",
    "iat": int(time.time()),
    "exp": int(time.time()) + 3600,  # expires in 1 hour
}

# Sign with HS256 (default)
token = jwt.encode(payload, "your-256-bit-secret", algorithm="HS256")
# → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi..."

# Verify and decode
decoded = jwt.decode(token, "your-256-bit-secret", algorithms=["HS256"])
# → {"sub": "user-123", "name": "Alice", "iat": 1717200000, "exp": 1717203600}
Node.js (jsonwebtoken)
const jwt = require('jsonwebtoken')

const payload = {
  sub: 'user-123',
  name: 'Alice',
  role: 'admin',
}

// Sign — iat is added automatically
const token = jwt.sign(payload, 'your-256-bit-secret', {
  algorithm: 'HS256',
  expiresIn: '1h',    // sets exp claim
  issuer: 'auth.example.com',  // sets iss claim
})

// Verify
const decoded = jwt.verify(token, 'your-256-bit-secret')
// → { sub: 'user-123', name: 'Alice', role: 'admin', iat: ..., exp: ... }
Go (golang-jwt)
package main

import (
    "fmt"
    "time"
    "github.com/golang-jwt/jwt/v5"
)

func main() {
    claims := jwt.MapClaims{
        "sub":  "user-123",
        "name": "Alice",
        "iat":  time.Now().Unix(),
        "exp":  time.Now().Add(time.Hour).Unix(),
    }

    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    signed, _ := token.SignedString([]byte("your-256-bit-secret"))
    fmt.Println(signed)
    // → eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOi...
}

الأسئلة المتكررة

ما الفرق بين ترميز JWT وفك تشفيره؟
ترميز JWT يُنشئ رمزًا موقَّعًا من header وpayload ومفتاح سري. فك التشفير يعكس العملية — يقرأ الـ header والـ payload المُشفَّرَين بـ base64url ويحوِّلهما إلى JSON. فك التشفير لا يتطلب المفتاح؛ أما الترميز فيتطلبه دائمًا لأن التوقيعة يجب أن تُحسَب.
ما الطول المثالي لمفتاح JWT السري؟
لـ HS256، استخدم سرًا بطول 256 بت على الأقل (32 بايت). لـ HS384، استخدم 384 بت على الأقل (48 بايت). لـ HS512، استخدم 512 بت على الأقل (64 بايت). المفاتيح الأقصر مقبولة تقنيًا لدى معظم المكتبات لكنها تُضعف الأمان الفعلي لتوقيع HMAC. أنشئ المفاتيح السرية بمولِّد أرقام عشوائية تشفيري، لا بعبارة مرور يختارها الإنسان.
هل من الآمن استخدام هذه الأداة بمفاتيح سرية حقيقية؟
تعالج هذه الأداة كل شيء في متصفحك باستخدام Web Crypto API — لا تُرسَل أي بيانات إلى أي خادم. ومع ذلك، تجنَّب لصق مفاتيح الإنتاج في أي أداة ويب كممارسة أمنية عامة. لإدارة مفاتيح الإنتاج، استخدم متغيرات البيئة أو مدير أسرار مثل HashiCorp Vault أو AWS Secrets Manager.
هل أختار HS256 أم RS256 لتطبيقي؟
استخدم HS256 حين تتولى نفس الخدمة إنشاء الرموز والتحقق منها — فهو أسرع وأبسط. استخدم RS256 (غير المتماثل) حين تحتاج خدمات خارجية إلى التحقق من رموزك دون امتلاك القدرة على إنشائها. RS256 شائع في موفِّري OAuth 2.0 وOpenID Connect ومعماريات SaaS متعددة المستأجرين.
لماذا تنتهي صلاحية JWT فور إنشائه؟
مطالبة exp تستخدم طوابع Unix الزمنية بالثواني لا بالمللي ثانية. إذا ضبطت exp على Date.now() (الذي يُعيد قيمة بالمللي ثانية)، سيبدو الرمز أنه ينتهي بعد آلاف السنين — أو إذا استخدمت قيمة بالمللي ثانية حيث تُتوقَّع قيمة بالثانية، قد تُفسِّر المكتبات الرمز على أنه منتهي الصلاحية. استخدم دائمًا Math.floor(Date.now() / 1000) في JavaScript أو int(time.time()) في Python.
هل يمكنني تخزين بيانات حساسة في payload الـ JWT؟
يمكن ذلك، لكن لا يُنصح به. الـ payload في JWT مُشفَّر بـ base64url وليس مُعمَّى — أي شخص يمتلك الرمز يستطيع قراءة المطالبات. لا تخزِّن كلمات المرور أو أرقام بطاقات الائتمان أو البيانات الشخصية في الـ payload. إذا كان يجب تضمين معلومات حساسة، استخدم JWE (JSON Web Encryption) كما هو معرَّف في RFC 7516، الذي يُشفِّر الـ payload بأكمله.
ماذا يحدث إذا غيَّرت payload بعد التوقيع؟
تصبح التوقيعة غير صالحة. تُحسَب توقيعة HMAC فوق البايتات الدقيقة للـ header والـ payload المُشفَّرَين. أي تغيير — حتى إضافة مسافة أو تعديل حرف واحد — ينتج توقيعةً مختلفةً تمامًا. أي مُحقِّق مُطبَّق بشكل صحيح سيرفض الرمز بخطأ عدم تطابق التوقيعة.