مقدمه ای بر JSON Web Tokens

جدید: کتابچه راهنمای JWT را به صورت رایگان دریافت کنید و JWT ها را عمیقاً یاد بگیرید!

JSON Web Token چیست؟

JSON Web Token (JWT) یک استاندارد باز (RFC 7519) است که یک روش فشرده و مستقل را برای انتقال ایمن اطلاعات بین طرفین به عنوان یک شی JSON تعریف می کند. این اطلاعات به دلیل امضای دیجیتالی قابل تأیید و اعتماد است. JWT ها را می توان با استفاده از یک رمز (با الگوریتم HMAC) یا یک جفت کلید عمومی/خصوصی با استفاده از RSA یا ECDSA امضا کرد.

اگرچه JWT ها می توانند رمزگذاری شوند تا رازداری بین طرفین نیز فراهم شود، اما ما بر روی توکن های امضا شده تمرکز خواهیم کرد. توکن های امضا شده می توانند یکپارچگی ادعاهای موجود در آن را تأیید کنند، در حالی که توکن های رمزگذاری شده آن ادعاها را از طرف های دیگر پنهان می کنند. هنگامی که نشانه ها با استفاده از جفت کلید عمومی/خصوصی امضا می شوند، امضا همچنین تأیید می کند که تنها طرفی که کلید خصوصی را در اختیار دارد، آن را امضا کرده است.

چه زمانی باید از JSON Web Tokens استفاده کنید؟

در اینجا چند سناریو وجود دارد که در آن توکن های وب JSON مفید هستند:

مجوز: این رایج ترین سناریو برای استفاده از JWT است. هنگامی که کاربر وارد سیستم می شود، هر درخواست بعدی شامل JWT می شود و به کاربر اجازه می دهد به مسیرها، خدمات و منابعی که با آن توکن مجاز هستند دسترسی داشته باشد. Single Sign On قابلیتی است که امروزه به طور گسترده از JWT استفاده می کند، زیرا سربار کوچک آن و توانایی آن برای استفاده آسان در دامنه های مختلف است.

تبادل اطلاعات: JSON Web Tokens راه خوبی برای انتقال امن اطلاعات بین طرفین است. از آنجا که JWT ها را می توان امضا کرد - برای مثال، با استفاده از جفت کلید عمومی / خصوصی - می توانید مطمئن باشید که فرستنده همان چیزی است که می گوید. علاوه بر این، از آنجایی که امضا با استفاده از هدر و بار محاسبه می شود، می توانید تأیید کنید که محتوا دستکاری نشده است.

ساختار JSON Web Token چیست؟

در شکل فشرده خود، توکن های وب JSON از سه قسمت تشکیل شده است که با نقطه ( . ) از هم جدا شده اند که عبارتند از:

بنابراین، یک JWT معمولاً به شکل زیر است.

بیایید بخش های مختلف را تجزیه کنیم.

سرتیتر

هدر معمولاً از دو بخش تشکیل شده است: نوع توکن که JWT است و الگوریتم امضای مورد استفاده مانند HMAC SHA256 یا RSA.

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

ظرفیت ترابری

قسمت دوم توکن، payload است که شامل ادعاها است. ادعاها اظهاراتی در مورد یک نهاد (معمولاً کاربر) و داده های اضافی هستند. سه نوع دعاوی وجود دارد: دعاوی ثبتی، عمومی و خصوصی.

ادعاهای ثبت شده: اینها مجموعه ای از ادعاهای از پیش تعریف شده هستند که اجباری نیستند اما توصیه می شوند تا مجموعه ای از ادعاهای مفید و قابل همکاری را ارائه دهند. برخی از آنها عبارتند از: iss (صادرکننده)، exp (زمان انقضا)، sub (موضوع)، aud (مخاطب) و غیره.

توجه داشته باشید که نام ادعاها فقط سه کاراکتر هستند تا اینکه JWT فشرده باشد.

ادعاهای عمومی: این ادعاها می توانند به دلخواه توسط کسانی که از JWT استفاده می کنند تعریف شوند. اما برای جلوگیری از برخورد، آنها باید در IANA JSON Web Token Registry تعریف شوند یا به عنوان یک URI که حاوی فضای نام مقاوم در برابر برخورد است تعریف شوند.

ادعاهای خصوصی: اینها ادعاهای سفارشی هستند که برای به اشتراک گذاشتن اطلاعات بین طرفینی که در مورد استفاده از آنها توافق می کنند ایجاد می شوند و ادعاهای ثبت شده یا عمومی نیستند.

یک بار نمونه می تواند این باشد:

پس بار بار به صورت Base64Url کدگذاری می شود تا قسمت دوم JSON Web Token را تشکیل دهد.

توجه داشته باشید که برای نشانه های امضا شده، این اطلاعات، اگرچه در برابر دستکاری محافظت می شوند، برای هر کسی قابل خواندن است. اطلاعات محرمانه را در محموله یا عناصر هدر JWT قرار ندهید مگر اینکه رمزگذاری شده باشد.

امضا

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

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

از امضا برای تأیید عدم تغییر پیام در طول مسیر استفاده می شود، و در مورد نشانه هایی که با کلید خصوصی امضا شده اند، همچنین می تواند تأیید کند که فرستنده JWT همان کسی است که می گوید.

همه را کنار هم گذاشتن

خروجی سه رشته Base64-URL است که با نقطه هایی از هم جدا شده اند که می توانند به راحتی در محیط های HTML و HTTP منتقل شوند، در حالی که در مقایسه با استانداردهای مبتنی بر XML مانند SAML فشرده تر هستند.

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

اگر می خواهید با JWT بازی کنید و این مفاهیم را عملی کنید، می توانید از jwt.io Debugger برای رمزگشایی، تأیید و تولید JWT استفاده کنید.

توکن های وب JSON چگونه کار می کنند؟

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

هر زمان که کاربر بخواهد به یک مسیر یا منبع محافظت شده دسترسی پیدا کند، عامل کاربر باید JWT را، معمولاً در سربرگ مجوز با استفاده از طرح حامل ارسال کند. محتوای هدر باید به شکل زیر باشد:

این می تواند ، در موارد خاص ، مکانیسم مجوز بدون تابعیت باشد. مسیرهای محافظت شده سرور برای یک JWT معتبر در عنوان مجوز بررسی می کند و در صورت حضور ، به کاربر اجازه دسترسی به منابع محافظت شده را می دهد. اگر JWT حاوی داده های لازم باشد ، ممکن است نیاز به پرس و جو از پایگاه داده برای برخی از عملیات کاهش یابد ، اگرچه ممکن است همیشه اینگونه نباشد.

توجه داشته باشید که اگر نشانه های JWT را از طریق هدرهای HTTP ارسال می کنید ، باید سعی کنید از بزرگ شدن آنها جلوگیری کنید. برخی از سرورها بیش از 8 کیلوبایت در هدر را نمی پذیرند. اگر می خواهید اطلاعات زیادی را در یک نشانه JWT جاسازی کنید ، مانند با درج تمام مجوزهای کاربر ، ممکن است به یک راه حل جایگزین مانند مجوز ریز و ریز Auth0 نیاز داشته باشید.

اگر نشانه در عنوان مجوز ارسال شود ، اشتراک منابع متقاطع (COR) مسئله ای نخواهد بود زیرا از کوکی ها استفاده نمی کند.

نمودار زیر نشان می دهد که چگونه JWT به دست می آید و برای دسترسی به API یا منابع استفاده می شود:

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

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

چرا باید از نشانه های وب JSON استفاده کنیم؟

بیایید در مورد مزایای توکن های وب JSON (JWT) در مقایسه با نشانه های وب ساده (SWT) و نشانه های امنیتی نشانه های نشانه امنیتی (SAML) صحبت کنیم.

از آنجا که JSON نسبت به XML کمتری دارد ، وقتی اندازه آن رمزگذاری شود نیز کوچکتر است و JWT را از SAML جمع و جور تر می کند. این باعث می شود JWT انتخاب خوبی در محیط های HTML و HTTP باشد.

از نظر امنیتی ، SWT فقط با استفاده از الگوریتم HMAC می تواند به صورت متقارن توسط یک راز مشترک امضا شود. با این حال ، نشانه های JWT و SAML می توانند از یک جفت کلید عمومی/خصوصی به شکل یک گواهی X. 509 برای امضای استفاده کنند. امضای XML با امضای دیجیتال XML بدون معرفی سوراخ های امنیتی مبهم در مقایسه با سادگی امضای JSON بسیار دشوار است.

پارسرهای JSON در بیشتر زبانهای برنامه نویسی متداول هستند زیرا مستقیماً به اشیاء نقشه می کشند. در مقابل ، XML نقشه برداری از سند طبیعی به اگزات ندارد. این کار کار با JWT را از ادعاهای SAML آسان تر می کند.

با توجه به استفاده ، JWT در مقیاس اینترنت استفاده می شود. این امر سهولت پردازش سمت مشتری از Token JSON در سیستم عامل های مختلف ، به ویژه موبایل را برجسته می کند.

مقایسه طول JWT رمزگذاری شده و یک SAML رمزگذاری شده

اگر می خواهید اطلاعات بیشتری در مورد توکن های وب JSON بخوانید و حتی از آنها برای انجام تأیید اعتبار در برنامه های خود استفاده کنید ، در صفحه فرود JSON Token در Auth0 مرور کنید.

امروز با JWT شروع کنید

jwt.io توسط auth0 برای شما آورده شده است

با استفاده از Auth0 در هر پشته و هر دستگاه در کمتر از 10 دقیقه ، تأیید هویت را با JWTS با اطمینان اجرا کنید.< SPAN> پارسرهای JSON در بیشتر زبانهای برنامه نویسی متداول هستند زیرا آنها مستقیماً به اشیاء نقشه می کشند. در مقابل ، XML نقشه برداری از سند طبیعی به اگزات ندارد. این کار کار با JWT را از ادعاهای SAML آسان تر می کند.