چرا Device Session و User Account Session یکی نیستند
بعد از جدا کردن Person از User، تلهٔ بعدی این است که هر چیزی که لاگین میماند را در یک آبجکت Session بریزید.
بیشتر اپها یک «Session» دارند: وارد میشوید، cookie میگیرید، خارج میشوید. تا وقتی این سؤالها مطرح نشوند کار میکند:
- قبل از login، این browser کیست؟
- میتوانم یک laptop را قطع کنم بدون اینکه همهٔ deviceها بمیرند؟
- اگر refresh token دزدیده شد، Account را باطل کنم یا Device را؟
این سؤالها مجبورم کرد به جداسازی دوم برسم: Device Session در برابر User Account Session.
دو لایه، دو مسئولیت
| Device Session | User Account Session | |
|---|---|---|
| وقتی وجود دارد که… | اپ باز شود (حتی guest) | کسی authenticate کند |
| جواب میدهد به | کدام client / browser / install؟ | کدام Account اینجا فعال است؟ |
| بعد از logout زنده میماند؟ | معمولاً بله | خیر |
| وابسته به | fingerprint کلاینت، IP، نشانههای geo | User Account + یک Device Session |
| شعاع آسیب compromise | یک client | یک login روی یک client |
User Account Session به Device Session وابسته است. بدون context معتبر Device، توکن Account را refresh نکنید. این ترتیب عمدی است — و دوباره در Frontend Edge ظاهر میشود.
چرا guest به Device Session نیاز دارد
Rate limit، سیگنال abuse، ارسال OTP و تشخیص «device جدید» همه به هویت پایدار client قبل از login نیاز دارند.
بدون لایهٔ Device، هر درخواست anonymous یا:
- نویز بدون state است (سخت برای محافظت)، یا
- به «anonymous user جعلی» تبدیل میشود (مدل Person / User را آلوده میکند)
Device Session ترافیک guest را داخل Identity نگه میدارد بدون ساختن آدم جعلی.
Multi-device طبیعی میشود
همان شخص. سه client. سه Device Session. در صورت نیاز سه User Account Session روی همان Account.
Logout روی laptop، User Account Session همان device را تمام میکند. Phone لاگین میماند. Tablet میتواند guest شناختهشده بماند.
هر Session چه چیزی نگه میدارد
Device Session به client context متمایل است: IP رمزشده، نشانههای country / city، OS، browser، برند device — کافی برای risk، بدون اینکه device را با شخص یکی بداند.
User Account Session به access context متمایل است: کدام Account، روی کدام Device، expiry، اشارهگر refresh فعلی.
هر دو برای فیلدهای حساس از envelope encryption (DEK بهازای ردیف) استفاده میکنند. Session «فقط claimهای JWT» نیست.
Failure modeهایی که تبدیل به نیاز طراحی میشوند
| سناریو | واکنش اشتباه single-session | واکنش دو لایه |
|---|---|---|
| کاربر logout میکند | همهچیز از جمله هویت client پاک شود | UA تمام؛ DS بماند |
| refresh دزدیدهشده روی phone | همهٔ loginها همهجا بمیرند (یا هیچکدام) | همان Session / family compromise شود |
| browser جدید | انگار جهان از صفر شروع شده | DS جدید، بعد login → UA |
| tabهای موازی refresh | یک blob با خودش میجنگد | سخت است — ولی family + single-flight در Edge کمک میکند |
برداشت معماری
پروتکلهای Authentication به شما token میدهند. مدل Session میگوید آن tokenها یعنی چه.
اگر «Session» هم «client شناختهشده» باشد هم «Account لاگینشده»، دیر یا زود روی logout، theft و جریان guest با خودتان میجنگید.
بعد
Tokenها Session نیستند. فصل بعد دربارهٔ Refresh Token Family، rotation، و reuse detection است — مکانیزمی که theft را قابلکشف میکند.
ادامه: Refresh Token Families.