یک سرویس مرجع، نه پنج تا
پنل مشتری، چت CRM، فرم حضوری عمومی، پرداخت و وفاداری آینده همه باید یک شمارهی موبایل را تأیید کنند. اگر رها شوند، هرکدام منطق هویت خودش را میسازد و از هم فاصله میگیرند.
هدف یک سرویس واحد و مرجع تأیید موبایل است که هر سطح صدایش میزند. آداپتورها میتوانند استفادهاش کنند؛ اجازه ندارند کنارش منطق هویت رقیب پیاده کنند.
fail-closed، بهطور پیشفرض
هویتهای تکراری خودکار ادغام نمیشوند — fail-closed میشوند و منتظر بازبینی دستی میمانند. سیستمی که دربارهی هویت مشتری حدس بزند، بالاخره طوری اشتباه حدس میزند که پول یا اعتماد هزینه میکند.
پیشفرض امن، توقف و پرسیدن است، نه ادامه و امیدواری.
طراحی پیش از اجرا
نسخهی اول هیچ اندپوینت احراز هویت و هیچ هوکی ثبت نمیکند و هیچ مهاجرت، نوشتن دیتابیس، کوکی یا فراخوان ارائهدهندهای انجام نمیدهد. runtimeاش عمداً غیرعملیاتی است.
این ناقصبودن نیست — ترتیب است. تصمیم معماری، قرارداد API، مدل داده، توالیهای امنیتی و threat model وجود دارند و تأیید شدهاند پیش از آنکه چیزی اجرا شود.
دروازههای تأیید مرحلهای
پروداکشن فقطخواندنی میماند تا تأییدهای صریح و مرحلهای برسند: طراحی، استیجینگ، مهاجرت، shadow، پذیرش داخلی، پایلوت، و در نهایت یک go/no-go تازه برای پروداکشن.
هر دروازه فقط قدم خودش را مجاز میکند. هیچچیز در انتشار خودکار نیست و هیچ دروازهای دروازهی بعدی را تضمین نمیکند.
چرا هویت را اینطور میسازم
رازها، مقادیر OTP و شمارههای کامل موبایل هیچوقت وارد گیت یا لاگ نمیشوند. تغییرات اسکیما افزایشی، نسخهدار، فقط InnoDB و هیچوقت از یک درخواست عمومی اجرا نمیشوند.
هویت تنها زیرسیستمی است که در آن سریعرفتن با بیاحتیاطی یکی است. انضباط، خودِ تحویل است.
کارهای مرتبط
برای جزئیات پیادهسازی، Customer Identity Core — نمایش و نمایش امنیت استیجینگ را ببینید. همچنین میتوانید کتابخانهی پروژهها و کیساستادیها را مرور کنید.