مشکل
رویکرد استاندارد صنعت برای یک سیستم احراز هویت توکن، استفاده از JWT با طول عمر محدود – “شماره شناسه” – با نقاط پایانی سرویس است، که به طور دوره ای احراز هویت مجدد قوی تر را با یک سیستم احراز هویت مرکزی مجبور می کند.
این نشانه‌های شناسه «آفلاین» تأیید می‌شوند – به این معنی که با سیستم احراز هویت مرکزی تماس گرفته نمی‌شود. این یک ویژگی مفید است زیرا امکان بهبود قابل توجه زمان پاسخ را برای نقطه پایانی فراهم می کند. به عنوان مثال، اگر سیستم احراز هویت مرکزی فقط در یک طرف اقیانوس اطلس قرار داشته باشد، تأیید آنلاین به حدود 200 میلی‌ثانیه تأخیر نقطه پایانی خدمات اضافی در طرف دیگر منجر می‌شود.
با این حال، اگر این نشانه‌ها فاش شوند، این بدان معناست که هیچ راهی برای نشان دادن این موضوع وجود ندارد – رمز شناسه تا زمانی که منقضی شود به طور غیرقابل برگشت معتبر باقی می‌ماند. افزودن چک ابطال آنلاین در وهله اول تمام مزایای استفاده از سیستم را از بین می برد.
یک راه حل
اولاً، هر کد id باید یک شناسه منحصر به فرد مرتبط با خود داشته باشد. استفاده مجدد از اینها در نهایت هیچ ضرری ندارد، تا زمانی که فقط پس از منقضی شدن توکن اصلی دوباره مورد استفاده قرار گیرند. من این را شناسه ابطال می نامم.
اگر قرار است نشانه ای به عنوان ابطال شده علامت گذاری شود – یا به طور خودکار از طریق خرابی های لکه دار یا به طور صریح – این شناسه ابطال به یک لیست (شاید یک جدول پایگاه داده) اضافه می شود.
یک نقطه پایانی جدید تأیید اعتبار مرکزی اکنون می‌تواند بررسی کند که آیا یک نشانه باطل شده است – یک بررسی ابطال آنلاین که در صورت امکان می‌خواهیم از آن اجتناب کنیم.
در مرحله بعد، من پیشنهاد می‌کنم یک فیلتر بلوم مشترک به سیستم اضافه شود که توسط سیستم احراز هویت مرکزی نگهداری می‌شود. می‌توان آن را با تغییر در نهادهای خدماتی از طریق انتشار-اشتراک (مثلاً Redis) پخش کرد یا به سادگی در یک آهنگ کوتاه (مثلاً یک بار در دقیقه یا حتی کمتر) دریافت کرد.
فیلتر بلوم یک مکانیسم احتمالی برای بهینه سازی تصمیم گیری در مورد اینکه آیا یک مقدار در یک مجموعه است، است، بنابراین با توزیع فقط مقادیر فیلتر بلوم، نیاز به بررسی بیشتر توکن ها در یک بررسی ابطال آنلاین را از بین می برد.
فیلترهای بلوم با بررسی اینکه آیا هش مقداری باینری یا به یک مقدار تبدیل شده است یا خیر کار می کنند – برای کاهش احتمال مثبت کاذب از هش های متعدد استفاده می شود. به عنوان مثال، اگر از SHA-256 و SHA-512 استفاده کنیم، می‌توانیم به صورت زیر بررسی کنیم:
# Pseudocode, really
def in_bloom(bloom, revocation_id):
if sha256(revocation_id) ^ bloom.sha256 != sha256(revocation_id):
return False
if sha512(revocation_id) ^ bloom.sha512 != sha512(revocation_id):
return False
return true
من پیشنهاد می کنم از مجموعه ای از HMAC-SHA-256 به عنوان الگوریتم های هش استفاده کنید. با استفاده از یک الگوریتم واحد، افزودن یک کلید HMAC اضافی از نظر کد بی اهمیت است و اجازه می دهد تا با تجربه عملیاتی آن را تغییر دهید.
این بدان معناست که فیلتر Bloom یک آرایه کوتاه از مقادیر باینری طولانی ۲۵۶ بیتی خواهد بود. یکی ممکن است برای سیستم های کوچکتر کافی باشد. فکر نمی‌کنم نیازی به بالاتر از چهار باشد، هرچند اندازه‌گیری کنید.
در نهایت، برای کاهش بار محاسباتی، من پیشنهاد می‌کنم مقادیر HMAC-SHA-256 شناسه ابطال را محاسبه کرده و آن را در JWT قرار دهید. این اساسا زمان CPU را با اندازه JWT معامله می کند.
نتیجه
در این مرحله، شما یک توکن قابل بازیابی با تأخیر ابطال بسیار کم دارید، اما بررسی های ابطال آفلاین مؤثر (و مزایای تأخیر این امر به شما می دهد).
