JSON Web Token (JWT) یک استاندارد باز (RFC 7519) می باشد که روشی کم حجم و جامعی را برای

انتقال امن اطلاعات بین طرفین، در قالب یک JSON object تعریف می کند. این اطلاعات تبادل شده، مطمئن و

قابل اعتماد می باشند زیرا به صورت دیجیتالی امضا شده اند.بهتر است که حتما از یک متخصص هک و امنیت مشاوره بگیرید.

JWT ها را می توان با استفاده از یک Secret (با بکارگیری از الگوریتم HMAC) یا جفت کلید عمومی و

خصوصی (با بکارگیری از الگوریتم های RSA یا ECDSA) امضا نمود.

توکن های امضا شده می توانند صحت محتوای موجود در آن را تایید کنند، در حالی که توکن های رمز گذاری

شده این محتوا را از طرفین مخفی نگه می دارند. هنگامی که توکن ها با استفاده از جفت کلید عمومی یا

خصوصی امضا شوند، این امضا تایید می کند که طرفی که دارنده کلید خصوصی می باشد آن را امضا کرده

است.

 

چه زمانی باید از JSON Web Token ها استفاده نمود

معمولاً در سناریو های زیر، از JWT ها استفاده می شود:

مجوز (Authorization): رایج ترین سناریو برای استفاده از JWT می باشد. در این روش پس از ورود کاربر، به

تمامی درخواست ها یک مقدار JWT افزوده می شود و برای کاربر این امکان را فراهم می کند تا به مسیر ها،

سرویس ها و یا منابعی که مجوز آن ها را دارد، دسترسی داشته باشد.

تبادل اطلاعات (Information Exchange): JWT ها روش خوبی جهت انتقال امن اطلاعات بین طرفین

می باشند. از آنجا که می توان JWT ها را امضا نمود ( به عنوان مثال، با استفاده از جفت کلید عمومی یا

خصوصی) می توان مطمئن شد که فرستندگان اطلاعات، همان افرادی هستند که ادعا می‌کنند. علاوه بر

این، از آنجا که امضا با استفاده از Header و Payload محاسبه می شود، می توان تایید کرد که محتوا

دستکاری شده است یا خیر.

 

ساختار JSON Web Token چگونه است

JWT از سه بخش مجزا که توسط یک (.) از یکدیگر جدا شده اند، تشکیل شده است که این موارد به شرح زیر

می باشد:

Header

هدر به طور معمول از دو بخش تشکیل شده است. نوع توکن، که JWT می باشد و الگوریتم امضا

مورد استفاده مانند HMAC SHA 256 یا RSA.

سپس، این JSON با مکانیزم Base64 کدگذاری شده و قسمت اول JWT را تشکیل می دهد.

Payload

قسمت دوم JWT را تشکیل می دهد و شامل claim می باشد. که این بخش معمولا ورودی هایی

همچون نام کاربری و اطلاعات اضافی را در خود جای می دهد. که این claim ها خود به سه دسته تقسیم

می شوند:

ثبت شده (Registered)

مجموعه از claim های از پیش تعریف شده می باشند که اجباری نیستند اما توصیه می شوند تا محتوایی

مفید و قابل تعامل را ارائه دهند. تعدادی از این نوع claim هایی که می توان نامبرد عبارتند از  iss (issuer)،

exp (expiration time)، sub (subject)، aud (audience) و ... .

عمومی (Public)

این نوع claim ها توسط کسانی که از JWT استفاده می کنند، می تواند تعریف شوند. اما برای جلوگیری از

تصادم در IANA JSON Web Token Registry یا به عنوان URI تعریف می شوند که حاوی یک فضا برای

جلوگیری از تصادم می باشد.

خصوصی (Private)

این calim های سفارشی سازی شده، برای به اشتراک گذاری اطلاعات می باشد که مابین طرفین، قرارداد شده است و مانند claim های ثبت شده و یا عمومی نمی باشند.

امضا (Signature)

برای ایجاد قسمت امضا، باید Header، Payload، Secret و الگوریتم مشخص شده پس از encode شدن، امضا

شوند. به عنوان مثال اگر از الگوریتم HMAC SHA256 استفاده شود، امضا به روش زیر ایجاد خواهد شد:

 

JSON Web Tokens چگونه کار می کند

در احراز هویت، وقتی کاربر با استفاده از اطلاعات کاربری با موفقیت وارد ناحیه کاربری خود می شود، یک

مقدار JWT بازگردانده می شود. از آنجائیکه توکن ها برای احراز هویت استفاده می شوند، برای جلوگیری از

بروز مشکلات امنیتی باید به آن ها توجه زیادی شود.

همچنین به دلیل مسائل امنیتی نمی توان session های حساس را در حافظه مرورگر ذخیره نمود. هر زمان که

کاربر قصد دسترسی به مسیر یا منابع حفاظت شده را داشته باشد، به طور معمول user agent باید JWT را

داخل پارامتر Authorization هدر در کنار Bearer ارسال کند.

محتوای هدر باید به صورت زیر باشد:

 

این امر می تواند یک مورد خاص برای مجوز به صورت stateless باشد. مسیر های محافظت شده سرور یک

JWT معتبر را در هدر Authorization بررسی می کنند و در صورت وجود، به کاربر اجازه می دهد تا به منابع

محافظت شده دسترسی پیدا کند.

اگر توکن در هدر Authorization ارسال شود، به دلیل عدم استفاده از کوکی ها، مشکلی برای

Cross-Origin Resource Sharing (CORS) ایجاد نخواهد شد.

تصویر زیر نحوه دستیابی و استفاده از JWT برای دستیابی به API ها یا منابع را نشان می دهد:

1. برنامه یا مجوز درخواست های کلاینت، اجازه دسترسی به سرور را می دهد. این کار از طریق یکی از جریان های مختلف صدور مجوز انجام می شود.
2. هنگامی که مجوز صادر می شود، سرور authorization یک توکن دسترسی باز می گرداند.
3. یک برنامه برای دسترسی به یک منبع محافظت شده (مانند یک API) از یک توکن دسترسی استفاده می کند.

توجه داشته باشید که توکن های امضا شده، تمام اطلاعات موجود در توکن را در اختیار کاربران یا طرفین قرار

می دهد، حتی اگر آن ها قادر به تغییر این اطلاعات نباشند.

این به این معناست که نباید مقدار Secret را در توکن قرار دهید.

 

نحوه شناسایی JWT

یک JWT معمولاً به صورت زیر می باشد:

xxxxx.yyyyy.zzzzz

چندین ویژگی وجود دارد که می توان JWT را شناسایی نمود:

• JWT ها حداقل از 100 کاراکتر تشکیل شده اند.
• JWT ها با مکانیزم Base64 رمز گذاری شده که شامل حروف و ارقام تشکیل شده است.
• JWT ها از سه بخش تشکیل و هر یک از این بخش ها با (.) جدا شده اند.
• معمولاً داخل هدر Authorization در کنار کلمه Bearer استفاده می شوند.

 

دلیل استفاده از JWT چیست؟

بیایید مزایای JSON Web Tokens (JWT) در مقایسه با Simple Web Tokens (SWT) و Security Assertion

Markup Language Token(SAML) بررسی نماییم.

از آنجائیکه JSON فشرده تر از XML است، هنگام Encode نمودن، اندازه آن کوچکتر است و JWT را فشرده تر

از SAML می کند. این امر باعث می شود JWT انتخاب خوبی در محیط های HTML و HTTP باشد.

از نظر امنیتی، SWT فقط می تواند با استفاده از الگوریتم HMAC توسط یک Secret مشترک امضا شود. با این

حال، توکن های JWT و SAML می توانند از یک جفت کلید عمومی و خصوصی در قالب یک گواهینامه x.509

برای امضا استفاده نمایند. امضا نمودن XML با XML Digital Signature بدون معرفی حفره های امنیتی مبهم،

هنگام مقایسه با سادگی امضا نمودن JSON بسیار دشوار است.

Parser های JSON در اکثر زبان های برنامه نویسی متداول هستند زیرا مستقیماً به object ها map

می‌شوند. در مقابل، XML فایلی برای Map کردن به Object ها ندارد، این موضوع کار با JWT را نسبت به

SAML آسان تر نموده است.

با توجه به کاربرد، JWT در مقیاس اینترنت استفاده می شود و این امر سهولت پردازش سمت کاربر را با

استفاده از JWT در پلتفرم های مختلف به ویژه موبایل برجسته کرده است.

 

 

منابع:

[0] www.jwt.io

[1] repository.root-me.org