چند روش Auth، یک مسیر Session
تیم محصول روشهای login جمع میکند: phone OTP، email/password، Google، شاید بعداً Apple. هر روش controller خودش، copy-paste «create user» خودش، و quirk Session خودش را میخواهد.
اینطور سه تعریف کمیمتفاوت از «logged in» میگیرید.
قانون معماری در این Identity BC ساده است:
چه چیزی مخصوص روش میماند
| روش | دغدغهٔ verification |
|---|---|
| Phone OTP | کد کوتاهعمر در cache، rate limit، search token تماس |
| Email + password | قوانین strength، verify با scrypt، شمارندهٔ lockout |
| OAuth | ID token / JWKS، audience، issuer؛ access token مربوط به provider را بیدلیل نگه ندار |
| Password reset | Reset session مات در cache؛ پاسخ همیشه ایمن (بدون email enumeration) |
اینها مال handler و adapterند — نه Aggregate مربوط به Session.
چه چیزی باید مشترک باشد
بعد از verify موفق:
- Provision — ساخت User Account + Contact برای هویت اولبار (یا link OAuth به email contact verified موجود)
- Establish — ساخت User Account Session + refresh family روی Device Session فعلی
- Events — registered در برابر authentication successful / failed
کاربر برگشتی create را رد میکند و باز همان مسیر establish را میزند. Subject جدید OAuth ممکن است بهجای create، به email contact verified موجود link شود.
لایهبندی که راز را از UI دور نگه میدارد
| دغدغه | مال کجاست |
|---|---|
| صفحهٔ login، UX ریدایرکت OAuth | Frontend |
| Client secret مربوط به provider | هرگز در browser |
| Verify credential، hashing، JWKS | Identity Service |
| صدور Session + refresh | Identity Service |
| قوانین Account linking | Identity Service |
Frontend مدرک را میفرستد (کد OTP، password، ID token). Identity تصمیم میگیرد کی هستید و session token برمیگرداند. Cookie و refresh در Edge delivery است — نه منبع حقیقت دوم.
گسترش بدون جراحی Schema
Providerهای OAuth یک adapter registryاند: provider جدید = verifier جدید + مقدار enum. نوع Contact از قبل Aggregate است؛ پس email در برابر phone جنگ ستون نیست.
Password credential به email contact آویزان است (۱:۱)، با فیلدهای failed-attempt و lockout. OAuth identity به Account آویزان است با search token از نوع HMAC روی sub — subject خام کلید query شفاف نیست.
چرا Convergence مهم است
بدون مسیر establish مشترک دیر یا زود:
- کاربران OTP با TTL Session متفاوت از password
- «Login» OAuth که device binding را فراموش میکند
- Reset که Sessionهایی را که فکر میکردید revoke کردهاید باطل نمیکند
با convergence، هر Authentication موفق یک معنی دارد: User Account Session روی Device شناختهشده، با refresh family، و eventهایی که بقیهٔ پلتفرم میتواند به آنها اعتماد کند.
بعد
آدمها و Accountها تمام دنیا نیستند. Organization، Employee و Location در همان bounded context موجودیتاند.
ادامه: Organizations و Location.