احراز هویت و ورود یکپارچه (SSO)
دو کلمه که مدام جای هم استفاده میشوند و تفکیکشان بیشتر مشکلات این حوزه را حل میکند:
احراز هویت یعنی تو کی هستی. اجازه یعنی حق داری چه کاری بکنی.
اولی یک بار در ابتدای نشست انجام میشود. دومی در هر عملیات و برای هر رکورد. سامانههایی که این دو را قاطی میکنند، معمولاً همانجایی میشکنند که در امنیت نرمافزار بهعنوان شایعترین رخنه گفتیم — کاربر وارد شده، پس فرض میشود مجاز است.
ورود یکپارچه چه چیزی را حل میکند
اگر سازمان شما پنج سامانه دارد، بدون SSO یعنی پنج نام کاربری، پنج رمز، و پنج جا که وقتی کارمندی میرود باید دسترسیاش قطع شود.
آن مورد آخر مهمتر از راحتی کاربر است. در عمل، همیشه یکی از آن پنج جا فراموش میشود.
با SSO یک جای مرکزی هویت را میداند و بقیه به آن تکیه میکنند. کارمند یک بار وارد میشود و قطع دسترسی هم در یک جا انجام میشود.
چطور کار میکند
کاربر به سامانه میرود، سامانه او را به مرکز هویت میفرستد، آنجا وارد میشود، و با یک توکن برمیگردد که میگوید کیست. سامانه توکن را بررسی میکند و راهش میدهد.
نکتهٔ کلیدی این است که سامانه هرگز رمز کاربر را نمیبیند. برای سازمانی با چند سامانه از چند پیمانکار، همین یک ویژگی ارزشش را دارد.
توکن را کجا نگه داریم
سؤالی که در هر پروژهٔ وب پیش میآید و جوابهای اینترنتیاش متناقضاند.
در localStorage: ساده، و در برابر اسکریپت تزریقشده بیدفاع. هر کدی که در صفحهٔ شما اجرا شود میتواند بخواندش.
در کوکی با پرچم HttpOnly: جاوااسکریپت به آن دسترسی ندارد. باید Secure و
SameSite هم داشته باشد.
توصیهٔ ما برای برنامههای وب، کوکی است. اگر مصرفکنندهٔ شما اپ موبایل است، ماجرا فرق دارد و توکن در حافظهٔ امن دستگاه مینشیند.
و در هر دو حالت: توکن دسترسی عمر کوتاه داشته باشد و توکن تازهسازی جدا و قابل ابطال باشد. توکنی که یک سال معتبر است و راهی برای باطلکردنش نیست، یعنی کارمندی که دیروز رفته هنوز دسترسی دارد.
اجازه: نقش کافی نیست
مدل نقشمحور نقطهٔ شروع خوبی است — «مدیر فروش» میتواند این کارها را بکند — و در سازمان واقعی خیلی زود کم میآورد.
چون سؤال معمولاً این نیست که «آیا این کاربر میتواند سفارش ببیند؟» بلکه این است که «آیا این کاربر میتواند این سفارش را ببیند؟» مدیر فروش منطقه الف نباید سفارشهای منطقهٔ ب را ببیند، هرچند نقشش یکی است.
پس در کنار نقش، معمولاً به محدودهٔ داده نیاز دارید: منطقه، شعبه، واحد سازمانی. این را از ابتدا در مدل داده پیشبینی کنید؛ افزودنش بعداً یعنی بازبینی هر کوئری در سامانه.
چیزهایی که در سازمانهای ایرانی لازم میشود
ورود با شمارهٔ موبایل و کد یکبارمصرف. برای سامانههای رو به مشتری، عملاً استاندارد شده. دو نکته: محدودیت نرخ روی ارسال کد، وگرنه هزینهٔ پیامک شما را کسی به بازی میگیرد؛ و مهلت کوتاه برای اعتبار کد.
احراز هویت با کارت ملی یا سامانههای حاکمیتی، در حوزههای مالی و سلامت. این اتصالها معمولاً مستندات کمی دارند و باید در برآورد بهعنوان یک قلم مستقل دیده شوند، نه بهعنوان جزئیات.
اتصال به دایرکتوری سازمانی برای کاربران داخلی، جایی که تعریف و حذف کاربر از قبل در واحد فناوری انجام میشود.
دو مورد که فراموش میشوند
فراموشی رمز. این مسیر معمولاً کمتر از خود ورود بازبینی میشود و همان اثر را دارد. لینک بازیابی باید یکبارمصرف و کوتاهعمر باشد، و پیام باید بیطرف بماند — اگر بگویید «این ایمیل ثبت نشده»، فهرست کاربرانتان قابل استخراج است.
خروج. در SSO، خروج از یک سامانه یعنی خروج از همه یا فقط از همان؟ هر دو قابل دفاع است؛ نداشتن تصمیم نه. کاربری که فکر میکند خارج شده و نشسته، یک مسئلهٔ امنیتی است.
اگر تازه شروع میکنید
برای یک سامانهٔ تنها، SSO لازم ندارید. احراز هویت ساده با کوکی امن و مدل نقش کافی است.
سراغ SSO وقتی بروید که سامانهٔ دوم آمد — نه زودتر، و نه دیرتر. دیرتر رفتن یعنی مهاجرت کاربران موجود، که همیشه از پیادهسازی اولیه سختتر است.
و در هر دو حالت، این سه را از روز اول رعایت کنید، چون افزودنشان بعداً گران است: بررسی اجازه در سرور و بهازای رکورد، محدودهٔ داده در مدل، و لاگ رویدادهای ورود و تغییر دسترسی.