در بخش پنجم، PKCE یا pixy را بررسی کردیم. در این بخش، موضوعاتی که در ارسال پیام ها در شبکه های اینترنتی و حملاتی که ممکن است اتفاق بیافتد، مانند تغییر محتوا، خواندن پیام و غیره را بررسی خواهیم کرد.
در این حوزه با دو موضوع Sign و Encryption روبرو هستیم.
موضوع encryption، به حفظ امنیت و محرمانگی اطلاعات می پردازد. در موضوع sign، به طریقی مطمئن می شویم که اطلاعات دریافت شده تغییر نکرده و اصالت داده ها حفظ شده است. حفظ اصالت ارسال کننده نیز در sign مطرح می شود. نکته ای که وجود دارد، یک پیام به صورت همزمان می تواند sign و encrypt باشد.
در این دو حوزه، با دو الگوریتم Symmetric و Asymmetric طرف هستیم.
الگوریتم symmetric برای sign و encrypt کردن، روش ساده ای را ارائه می کند. فرض کنید دو party به نام A و B داریم، که قرار است بین آن ها پیام ارسال و دریافت شود. یک کلید مشترک در دو سمت فرستنده و گیرنده داریم. پیام در زمان ارسال شدن با این کلید sign می شود و گیرنده از همان کلید برای باز کردن یا verify کردن پیام استفاده می کند.
نکته منفی که در الگوریتم های symmetric وجود دارد، از آنجایی که کلید مشترک است، لو رفتن کلید در هرکدام از partyها باعث باز شدن همه پیام ها می شود. در نتیجه امنیت کمتری دارد. و نکته مثبت آن، ساده بودن و سریع بودن است.
در الگوریتم asymmetric، ارسال کننده پیام دو کلید public key و private key دارد. public key می تواند در اختیار همه partyهای دیگر قرار بگیرد و private key یک کلید خصوصی است.
در sign کردن، party A پیام را از طریق private key خودش sign می کند و party B در زمان دریافت پیام، با استفاده از public key A پیام را verify و باز می کند.
در encrypt کردن، زمانی که party B می خواهد پیامی را به سمت A ارسال کند، پیام را از طریق public key A رمزگذاری می کند و ارسال می کند. و A با استفاده از private key خودش می تواند پیام را باز کند.
در الگوریتم های asymmetric، امنیت بالاتری وجود دارد اما پیچیده تر و کمی کندتر هستند.
در پروتکل هایی که امروزه در اینترنت داریم برای مثال https، از هر دو الگوریتم استفاده می شود.
Claim-Based Identity
داده هایی در توکن های امنیتی در authorization context و authentication context مربوط به کاربر، که توسط authorization server تایید شده است و یا خود کاربر مدعی شده است، اصلاحا claim گفته می شود.
JWT
مجموعه ای از استانداردها، با نام JSON Object Signing and Encryption (JOSE) وجود دارد که توسط IETF و در مورد sign و encrypt کردن داده های json در تعدادی از RFCها مطرح شده است و یکی از آنها JWT می باشد.
توکن JWT یک استاندارد برای sign و encrypt کردن claimها برای انتقال بین partyها می باشد و به سه بخش Payload ،Header و Signature تقسیم می شود. این سه بخش توسط کاراکتر نقطه ('.') از همدیگر جدا می شوند و هر بخشی base64url-encode می شود. در header اطلاعات کلی مربوط به یک توکن، مانند type و algorithm را می بینید که به ما کمک می کند تا بتوانیم متوجه آن توکن شویم. payload شامل claimها و داده ها می باشد. و از طریق signature می توانیم توکن sign شده را verify کنیم.
از cliamهای رایج که در توکن JWT وجود دارد، می توانیم به موارد زیر اشاره کنیم.
مخفف Issuer و ارسال کننده توکن است که معمولا با یک url مقداردهی می شود.
مخفف Subject و مشخص کننده سوژه توکن است. معمولا با identifier کاربر مقداردهی می شود و تمام cliamهای دیگر در مورد آن صحبت می کنند.
مخفف Audience و مشخص کننده مخاطب توکن است. می تواند با آرایه ای از StringOrURI باشد.
مخفف Expiration و مشخص کننده زمان expire شدن access token را نشان می دهد.
مخفف Not-Before و صادر کننده JWT با این claim مشخص می کند که توکن از چه زمانی به قبل نباید مورد استفاده قرار بگیرد.
مخفف Issued-At و مشخص کننده زمان صادر شدن توکن است.
مخفف JWT ID و یک شناسه است که ممکن است authorization server برای توکن در نظر بگیرد و برای شناسایی replay شدن توکن استفاده می شود.
مخفف Session ID است و session id کاربر در identity server می باشد.
مخفف Authentication Methods References و توسط سازمان استاندارد IANA ارائه شده است و مشخص می کند که جریان authentication در authorization server چطور اتفاق افتاده است. بعضی از partyها، نیاز دارند که روش authenticate کردن شما را بدانند. مقداری که معمولا برای آن مورد استفاده قرار می گیرد، pwd (Password) می باشد.
