رفتن به محتوای اصلی
مصطفی عفتی

درباره این پلتفرم

دفتر کاری زنده برای تجربه‌های مهندسی

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

همکار دانشجویی

  • خانم زهرا احسانی

    دانشجوی سابق · مشارکت‌کننده در توسعه پلتفرم

    خانم زهرا احسانی در دوران تحصیل روی بخش‌هایی از این پلتفرم کار کرد و با مشارکت‌های دقیق و کاربردی به توسعه آن کمک کرد. خوشحالم که اینجا از کارش قدردانی می‌کنم.

اینجا چه پیدا می‌کنید

  • مقاله‌ها، کتاب‌ها، آموزش‌ها و اسنیپت‌های کاربردی.
  • دوره‌ها و مسیرهای یادگیری مبتنی بر تجربه‌های واقعی مهندسی.
  • مطالعات موردی، پروژه‌های متن‌باز، آزمایش‌ها و انتشار محصولات.

با طراحی آگاهانه

  • تجربه دو‌زبانه فارسی و انگلیسی با پشتیبانی بومی از RTL.
  • رابط‌های سازگار با تم و کیبورد، با یک زبان بصری متمرکز.
  • توسعه محتوا و محصول به‌عنوان یک سیستم یکپارچه و نسخه‌بندی‌شده.

این پلتفرم پیوسته در حال تکامل است. بعضی بخش‌ها محصولاتی کامل‌اند و برخی دیگر آزمایش‌های فعالی که هم‌زمان با پیشرفت کار بهتر می‌شوند.

Refresh Token Families

Rotation و reuse detection در سطح family چگونه refresh token دزدیده‌شده را به compromise قابل‌کشف تبدیل می‌کند — برای Device و Account Session.
Mostafa Effati3 دقیقه مطالعهsoftware-architecture

Refresh Token به Family نیاز دارد، نه فقط Expiry

Access token کوتاه‌عمر توضیح ساده‌ای دارد. جایی که امنیت واقعاً زندگی می‌کند refresh است — و جایی که بیشتر سیستم‌ها کم‌طراحی می‌کنند.

یک refresh ساده‌لوحانه یک راز بلندعمر است: ارائه بده، access جدید بگیر. اگر نشت کند، مهاجم تا وقتی کسی نفهمد client مشروع به‌نظر می‌رسد.

راه‌حل «refresh را کوتاه‌تر کن و امیدوار باش» نیست. راه‌حل rotation با ردیابی family است.

Rotation در یک تصویر

هم Device Session و هم User Account Session همین الگو را دارند: هر ردیف refresh یک family id، اشاره‌گر اختیاری replaces، expiry و متادیتای revoke دارد. Aggregate مربوط به Session به refresh فعلی اشاره می‌کند.

چرا Family به‌جای یک راز mutable

رویکردچه چیزی می‌شکند
یک refresh mutable در DBrace بین tabها؛ بدون سیگنال theft
فقط JWT refresh بدون staterevoke سخت؛ reuse نامرئی
Rotation بدون familyیک توکن را می‌کشی، lineage را از دست می‌دهی
Rotation با familyreuse هر ancestor → کشتن کل زنجیره

Family تبار rotationهایی است که از یک login (یا device bootstrap) شروع شده. دلیل compromise در دامنه صریح است: token reuse، admin action، یا سیگنال مشکوک.

Reuse detection یعنی چه در عمل

وقتی refresh باطل‌شده (یا جایگزین‌شده) دوباره ارائه شود:

  1. Domain event مربوط به reuse-detected
  2. Session به حالت compromised
  3. باطل کردن family — نه فقط همان ردیف

نشت خاموش تبدیل می‌شود به شکست بلند و محلی: همان device / همان login می‌میرد. Deviceهای دیگر روی familyهای دیگر می‌توانند زنده بمانند.

Device و Account هر دو Family دارند

وسوسه‌انگیز است که family را فقط برای «توکن login» بگذارید. در مدل دو لایه، هم device refresh و هم account refresh رازهای باارزش‌اند.

  • سرقت Device Family → آن client دیگر قابل‌اعتماد نیست؛ Account Sessionهای روی آن پاس رایگان نمی‌گیرند
  • سرقت Account Family → آن login روی آن device مرده؛ بقیهٔ deviceها می‌مانند

Frontend باید اول Device را refresh کند، بعد Account را با access مؤثر Device. ترتیب اشتباه failureهای جعلی می‌سازد که شبیه bugاند و شما را به ضعیف‌کردن امنیت عادت می‌دهند.

دشمن پنهان: درخواست‌های موازی

Browser، HTML، RSC و prefetch را موازی می‌زند. همه cookie منقضی می‌بینند و همه همان توکن را refresh می‌کنند.

بدون هماهنگی یا:

  • reuse بی‌گناه (race خودتان) theft تلقی می‌شود، یا
  • هجوم به backend و UX شکننده

Identity همچنان صحت rotation را مالک است. Edge single-flight را مالک است تا یک process خودش را له نکند. این‌ها لایه‌های مکمل‌اند — فصل ۹ سمت Edge را می‌گوید.

برداشت

Expiry آسیب را محدود می‌کند. Family سرقت را کشف می‌کند.

اگر داستان refresh فقط «JWT بلندعمر تا logout» باشد، راز دارید — نه مدل امنیت Session.

بعد

OTP، password و OAuth دم در متفاوت به نظر می‌رسند. داخل دامنه باید روی یک مسیر session establishment همگرا شوند.

ادامه: Authentication Convergence.

اسناد مرتبط

منوی دستور

↑ ↓برای حرکت · Enter برای انتخاب · Esc برای بستن
ناوبری
اقدامات

Esc برای بستن · ⌘K برای باز/بسته کردن