مقدمه ای بر JWT و نحوه پیاده سازی

JWT

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

JWT دارای امضای دیجیتالی است، بنابراین اطلاعات، مورد اعتماد و تأیید شده است.JWT می تواند با استفاده از کلید عمومی/خصوصی (ECDSA یا RAS) امضاء و یا با الگوریتم HMAC رمزگذاری شود.JWT در توسعه ی وب بسیار مشهور است.

مقدمه

JSON Web Token یک استاندارد باز و قابل دسترس است که انتقال داده ها بین طرفین را به عنوان یک JSON فراهم می کند.

JWT دارای امضای دیجیتالی است، بنابراین اطلاعات، مورد اعتماد و تأیید شده است.

JWT می تواند با استفاده از کلید عمومی/خصوصی (ECDSA یا RAS) امضاء و یا با الگوریتم HMAC رمزگذاری شود.

JWT در توسعه ی وب بسیار مشهور است.

ساختار JWT

از سه بخش تشکیل می شود:

Header (هدر)

Payload (بسته ی اطلاعاتی)

Signature (امضاء)

همگی با نقطه (.) تفکیک شده اند. بنابراین JWT به اینصورت است – “hhhhhhhhhh.ppppppppp.ssssssss”.

Header

از دو بخش تشکیل می شود: الگوریتم hashing (نوعی رمزگذاری) که مورد استفاده قرار می گیرد مانند HMAC SHA256 یا RAS، و نوع نشانه، که JWT است.

مثال

{  
  "alg": "HS256",  
  "typ": "JWT"  
}  

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

Payload

دومین بخش JWT، یک payload است که حاوی claimها می باشد.

claimها عباراتی در رابطه با موجودیت، مانند کاربر، هستند. و همچنین، payload حاوی متادیتاهای اضافی است.

سه نوع Claim وجود دارد:

  • Registered (ثبت شده)
  • Public (عمومی)
  • Private (خصوصی)

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

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

در ادامه، claimهای ثبت شده آمده اند.

  •   Issuer : منتشر کننده
  •  Subject: فاعل
  • Audience :  مخاطب
  •  Expiration Time : زمان انقضاء
  • Not Before : نه پیش از اینکه
  •  Issued At : منتشر شده در زمان
  •   JWT ID : شناسه ی JWT

claimهای عمومی می توانند بصورت دلخواه توسط آن هایی که از JWTها استفاده می کنند تعریف شوند.

جهت اجتناب از برخوردها، claimها باید در IANA JSON Web Token Registry تعریف شده یا به عنوان یک نام عمومی، که حاوی یک فضای نام مقاوم در برار برخورد است، تعریف شوند.

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

این claimها نه ثبت شده و نه عمومی هستند.

مثال

{  
  "sub": "Test JWT",  
  "name": "Trivedi Jignesh",  
  "admin": true  
}  

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

Signature (امضاء)

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

signature/امضاء برای تأیید اینکه پیام در هنگام انتقال تغییر نیافته باشد، استفاده می شود.

مثال

اگر از الگوریتم HMAC SHA256 استفاده کنیم، امضاء بصورت زیر ایجاد خواهد شد.

HMACSHA256(  
  base64UrlEncode(header) + "." +  
  base64UrlEncode(payload),  
  secret)

خروجی، سه رشته ی base64 است که با نقطه (.) جدا شده اند که به راحتی می توان در درخواست های HTML و HTTP ارسال کرد و فشرده تر از Security Assertion Markup Language Tokens – XML based standards ( نشانه های زبان نشانه گذاری اثبات امنیت  استانداردهای مبتنی برXML است) . JWT در ادامه نشان داده شده است.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJUZXN0SldUIiwibmFtZSI6IlRyaXZlZGkgSmlnbmVzaCIsImFkbWluIjp0cnVlfQ==.X5ZYZxrVGlrcegeJmNjKj_dA02pDvfkQCjwAy2y3V9k  

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

JWT

نحوه ی کار JWT

مانند احراز هویت ، پس از اینکه کاربر با استفاده از اعتبارنامه های خود با موفقیت وارد سیستم شود، یک JSON Web Token بازگردانده خواهد شد.

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

نشانه ها همواره باید با هر درخواست، و بطور معمول در هدر Authorization (تأِیید)، با استفاده از طرح Bearer ارسال شوند.

Authorization: Bearer <<token>>  

این یک مکانیزم احراز هویت بدون حالت است که در آن وضعیت/حالت کاربر هیچگاه در حافظه ی سرور ذخیره نمی شود.

مسیر سرور، یک JSON Web Token معتبر را در هدر Authorization بررسی خواهد کرد و اگر حاضر باشد، کاربر مجاز خواهد بود تا به منابع حفاظت شده دسترسی یابد.

JSON Web Token حاوی تمامی اطلاعات مورد نیاز است.

امن ترین و ساده ترین راه برای پیاده سازی احراز هویت مبتنی بر JSON Web Token ، بکارگیری یکی از کتابخانه های متن باز موجود است.

در JWT.io، می توانیم کتابخانه های بسیاری را برای .NET، Python، Java، Ruby، Swift و … بیابیم.

انواع بسیاری از نشانه ها موجود هستند، مانند Simple Web Token ( نشانه ی وب ساده) ، نشانه ی SAML) Security Assertion Markup Language) زبان نشانه گذاری اثبات امنیت[ و JSON Web Tokens ( نشانه های وب ).

در این بخش، در رابطه با مزیت JSON Web Token بر SWT و نشانه ی SAML صحبت می کنیم.

JSON Web Token از XML مختصرتر است. هنگامیکه JSON Web Token  کدگذاری می شود، اندازه ی آن کوچکتر از داده های XML کدگذاری شده است، بنابراین JWT فشرده تر از SAML است.

به این دلیل است که JSON Web Token  انتخابی مناسب جهت ارسال در محیط های HTML و HTTP می باشد.

JSON Web Token  بطور نامتقارن توسط یک رمز مشترک با استفاده از الگوریتم HMAC امضاء شده است.

با این حال، JSON Web Token  و SAML می توانند از یک کلید عمومی/خصوصی در قالب گواهی X.509 برای امضاء استفاده کنند.

امضای XML با Digital Signature (امضای دیجیتالی) بدون معرفی حفره های امنیتی مبهم، بسیار دشوار است. این همان سادگی امضای JSON است.

JSON Web Token  به دلیل کیفیت نگاشت مستقیم به اشیاء در اکثر زبان های برنامه نویسی پشتیبانی می شود، درحالیکه XML، بطور طبیعی و ذاتی دارای نگاشت سند به شیء نیست.

بنابراین، کار با JSON Web Token آسان تر از نشانه ی SAML است.


زهره سلطانیان

نوشته‌های مرتبط

دیدگاه‌ها

*
*

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.