یکپارچه‌سازی لاگین‌های بین دامنه‌ای

Eiji Kitamura

معماری‌های کسب‌وکار مدرن اغلب چندین دامنه مجزا را در بر می‌گیرند. سازمان‌ها محیط‌های اختصاصی برای ویژگی‌های مختلف دارند - مانند brand.example برای بازاریابی، service-app.example برای محصول اصلی و support-portal.example برای خدمات مشتری. در حالت ایده‌آل، شما می‌خواهید یک تجربه ورود یکپارچه و واحد را هنگام پیمایش کاربران در این ویژگی‌ها ارائه دهید. با این حال، تیم‌های مهندسی اغلب این دامنه‌ها را با استفاده از تکنیک‌های موقت که باعث تکه‌تکه شدن می‌شوند، ادغام می‌کنند. این امر با ایجاد اختلال در جریان‌های تکمیل خودکار مدیریت رمز عبور و متوقف کردن پذیرش کلید عبور، مدیریت اعتبارنامه مرورگر داخلی را مختل می‌کند.

تکه‌تکه شدن هویت بین دامنه‌ای در چندین ویژگی وب.

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

یاد بگیرید که چگونه از استانداردها و راه‌حل‌های معماری (مانند متادیتا، آی‌فریم‌های بین‌دامنه‌ای، فدراسیون هویت و تجمیع زیردامنه) برای حل پراکندگی هویت بین‌دامنه‌ای و ارائه یک تجربه کاربری یکپارچه استفاده کنید.

راهکارهای رایج

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

درخواست‌های واکشی CORS

وقتی دامنه‌ها به طور مستقل عمل می‌کنند، رابط‌های کاربری اغلب به درخواست‌های fetch() بین مبدا و مقصد که به یک API احراز هویت متمرکز هدایت می‌شوند، متکی هستند که می‌توان با استفاده از Cross-Origin Resource Sharing (CORS) به طور ایمن آنها را مجاز دانست. از آنجایی که مرورگرها اغلب کوکی‌های بین سایتی را مسدود یا محدود می‌کنند، توسعه‌دهندگان می‌توانند به طور صریح این APIها را طوری طراحی کنند که توکن‌های احراز هویت، مانند JSON Web Tokens (JWTs) را در داخل JSON برگردانند، نه اینکه به هدرهای Set-Cookie تکیه کنند.

اشتراک‌گذاری پایگاه داده حساب‌ها

برای یکپارچه‌سازی هویت در بک‌اند بدون یکپارچه‌سازی‌های پیچیده فرانت‌اند، می‌توانید پایگاه داده کاربر آنها را متمرکز کنید. اگرچه چندین دامنه در یک پایگاه داده یکسان احراز هویت می‌شوند، اما تجربه ورود به فرانت‌اند آنها جداگانه باقی می‌ماند. این امر کاربران را مجبور می‌کند به خاطر بسپارند که از کدام دامنه‌ها از اعتبارنامه یکسانی استفاده کرده‌اند و این منجر به یک تجربه کاربری ضعیف می‌شود.

مشکلات مربوط به ورودهای نامرتبط

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

تکه‌تکه شدن مدیریت رمز عبور

بالاترین نقطه اختلاف، اختلال در برنامه‌های مدیریت رمز عبور است. برنامه‌های مدیریت رمز عبور، اطلاعات ذخیره شده را به منبع خاصی که در آن ثبت شده‌اند، متصل می‌کنند. این امر مانع از آن می‌شود که مرورگر، تکمیل خودکار را در دامنه‌های مختلف، حتی زمانی که متعلق به یک سازمان هستند، ارائه دهد.

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

از آنجا که نرم‌افزار مدیریت رمز عبور در این سایت‌ها غیرقابل اعتماد است، کاربران ممکن است ابزارهای این سایت‌ها را رها کنند. در عوض، آنها اغلب رمزهای عبور ضعیف و به یاد ماندنی ایجاد می‌کنند تا در جای دیگری دوباره از آنها استفاده کنند که امنیت کلی سازمان شما را کاهش می‌دهد.

درگاه فیشینگ

این اختلال به عنوان یک دروازه فیشینگ عمل می‌کند. امتناع یک مدیر رمز عبور از تکمیل خودکار در یک دامنه ناشناخته، یک مکانیسم دفاعی اولیه است. با ملزم کردن کاربران به وارد کردن دستی اعتبارنامه‌ها در URL های مختلف، شما ناخواسته کاربران آنها را برای قربانی شدن در حملات فیشینگ آموزش می‌دهید.

انسداد جاده با کلید عبور

وقتی از کلیدهای عبور استفاده می‌کنید، اصطکاک افزایش می‌یابد. معماری امنیتی اصلی WebAuthn به صورت رمزنگاری‌شده، کلیدهای عبور را کاملاً به یک شناسه طرف اتکا (RP ID) مشخص‌شده متصل می‌کند.

این یک "تله شناسه RP" ایجاد می‌کند. یک کلید عبور ثبت شده در brand.example در service-app.example غیرقابل استفاده است زیرا مرورگر دسترسی بین دامنه‌ای را رد می‌کند. برای جلوگیری از درخواست کاربران برای ثبت کلیدهای عبور مجزا برای هر سایت، باید این ویژگی‌ها را در یک شناسه RP واحد تجمیع کنید.

رویکردهای توصیه‌شده

برای ایجاد تداوم هویت، باید از یکپارچه‌سازی‌های ورود به سیستم موردی فاصله بگیرید و استانداردهای معماری شناخته‌شده را اتخاذ کنید:

• استفاده از فایل‌های پیکربندی فراداده : فایل‌های فراداده مانند پیوندهای دارایی دیجیتال و درخواست‌های مبدا مرتبط را میزبانی کنید تا یک زنجیره اعتماد رمزنگاری ایجاد کنید. این امر امکان اشتراک‌گذاری یکپارچه اعتبارنامه و کلید عبور را در دامنه‌ها و برنامه‌های تلفن همراه مختلف فراهم می‌کند. این رویکرد، یک راه‌حل کم‌هزینه و بی‌سروصدا برای چندپارگی هویت است که نیازی به معماری مجدد پیچیده زیرساخت وب موجود ندارد.
• استفاده از iframe های بین مبدایی : یک iframe مرکزی برای احراز هویت در یک طرف وابسته تعبیه کنید تا اعتبارنامه‌ها و کلیدهای عبور ذخیره شده را در سایت‌های مختلف به هم متصل کند. این رویکرد از سیاست مجوزها و کوکی‌های پارتیشن‌بندی شده برای ایجاد یک تجربه ورود یکپارچه و در متن استفاده می‌کند و در عین حال مرزهای امنیتی سختگیرانه‌ای را از طریق CSP و پیام‌رسانی بین اسنادی حفظ می‌کند.
• پیروی از استاندارد فدراسیون هویت : پروتکل‌های استاندارد صنعتی مانند OpenID Connect را برای متمرکز کردن احراز هویت در یک دامنه اختصاصی ارائه دهنده هویت (IdP) اتخاذ کنید. این امر، فرآیند ورود به سیستم را از طریق ریدایرکت‌های امن، رسمی می‌کند و ادغام‌های شکننده را با یک راهکار شخص ثالث قابل اعتماد و مقیاس‌پذیر جایگزین می‌کند.
• ادغام زیردامنه‌ها : انتقال به زیردامنه‌های تحت یک ریشه مشترک. این امر امکان اشتراک‌گذاری یکپارچه نشست را از طریق کوکی‌های wildcard و تداوم کلید عبور در کل دامنه قابل ثبت فراهم می‌کند. بسیاری از مدیران رمز عبور می‌توانند دامنه ریشه مشترک را تشخیص دهند و به طور خودکار اعتبارنامه‌های ذخیره شده را در زیردامنه‌های مرتبط پیشنهاد دهند.

استفاده از فایل‌های پیکربندی فراداده

یکی از چالش‌های اصلی هویت بین دامنه‌ای، تکه‌تکه شدن اطلاعات ورود ذخیره شده است. مدیران رمز عبور، دامنه‌ها و برنامه‌های مختلف را به عنوان موجودیت‌های کاملاً مجزا در نظر می‌گیرند، که این امر مانع از تکمیل خودکار اطلاعات ورود ذخیره شده در یک دامنه به دامنه دیگر می‌شود.

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

برای اطمینان از اینکه پلتفرم‌ها و اکوسیستم‌های مختلف را پوشش می‌دهید، از دو فایل پیکربندی مختلف استفاده کنید:

• مدیریت رمز عبور گوگل در اندروید و کروم : یک فایل JSON از نوع Digital Asset Links (DAL) را در مسیر /.well-known/assetlinks.json میزبانی کنید تا یک رابطه اعتماد قابل تأیید بین برنامه‌ها و وب‌سایت‌های مرتبط با یک سازمان برقرار شود. این اعتماد، پیوندهای عمیق در برنامه‌ها و اشتراک‌گذاری اعتبارنامه یکپارچه را امکان‌پذیر می‌کند، جایی که رمزهای عبور ذخیره شده در وب به طور خودکار وب‌سایت‌های مرتبط را تکمیل می‌کنند (اگرچه اشتراک‌گذاری کلیدهای عبور در چندین دامنه وب همچنان مستلزم درخواست‌های مبدا مرتبط است). برای اطلاعات بیشتر به راهنمای اشتراک‌گذاری اعتبارنامه یکپارچه مراجعه کنید.

• رمزهای عبور اپل در iOS و سافاری : یک فایل انجمن سایت اپلیکیشن اپل (AASA) را در /.well-known/apple-app-site-association میزبانی کنید تا زنجیره اعتماد رمزنگاری لازم برای پل زدن بین حالت‌های رمزهای عبور اپل در برنامه‌های iOS و سافاری ایجاد شود. برای پشتیبانی از اکوسیستم‌های شخص ثالث، می‌توانید این دامنه‌های مرتبط را به صورت مرکزی با استفاده از یک مخزن جمع‌سپاری شده اعلام کنید. انجام این کار تضمین می‌کند که ابزارهای مستقل (مانند 1Password که صریحاً این مخزن را دریافت می‌کند) نیز زمینه هویت مشترک را تشخیص دهند. برای کسب اطلاعات بیشتر در مورد انجمن سایت اپلیکیشن اپل، بخش پشتیبانی از دامنه‌های مرتبط را مطالعه کنید.

برای فعال کردن کلیدهای عبور در دامنه‌های وب مختلف و رفع مشکل مسدود شدن کلید عبور، توسعه‌دهندگان می‌توانند یک فایل درخواست‌های مبدا مرتبط (ROR) را در /.well-known/webauthn میزبانی کنند. ROR به صراحت دامنه‌های مجاز را که مجاز به اشتراک‌گذاری ایمن شناسه RP کلید عبور یکسان هستند، اعلام می‌کند. برای کسب اطلاعات بیشتر در مورد درخواست‌های مبدا مرتبط، بخش «اجازه استفاده مجدد از کلید عبور در سایت‌های خود با درخواست‌های مبدا مرتبط» را مطالعه کنید.

• مزایا:
  • رفع مشکل در پس‌زمینه برای کاربران نهایی: این قابلیت کاملاً در پس‌زمینه کار می‌کند، که به طور خودکار مشکل تکه‌تکه شدن فرم‌های تکمیل خودکار را برطرف کرده و بدون هیچ تغییر قابل مشاهده‌ای در تجربه کاربری، تداوم رمز عبور را در سطح سیستم‌عامل یا مرورگر برقرار می‌کند.
  • پیاده‌سازی ساده: این یک راه‌حل کم‌هزینه است که فقط به میزبانی فایل‌های JSON استاتیک نیاز دارد. نیازی به معماری مجدد backend یا منطق پیچیده تبادل توکن ندارد.
  • زیرساخت‌های موجود را حفظ می‌کند: شما می‌توانید بدون تغییر برند یا ادغام دامنه‌هایتان، سفر بین دامنه‌ای را به طور قابل توجهی بهبود بخشید.
• معایب:
  • محدودیت‌های پلتفرم: پلتفرم‌ها معمولاً محدودیت‌های سختگیرانه‌ای را بر ROR اعمال می‌کنند. به عنوان مثال، کروم یک شناسه RP واحد را به حداکثر ۵ برچسب eTLD+1 مرتبط محدود می‌کند. برای مثال، example.co.uk و example.de برچسب example eTLD+1 یکسانی دارند؛ با این حال، example-rewards.com از یک برچسب example-rewards جداگانه استفاده می‌کند. اگر شما یک مجموعه دامنه گسترده یا متنوع را مدیریت می‌کنید، این محدودیت‌ها ممکن است کافی نباشند.
  • افزایش تأخیر عملیاتی: حل کردن فایل‌های متادیتا نیاز به یک رفت و برگشت شبکه اضافی دارد که باعث افزایش تأخیر هنگام پردازش احراز هویت توسط مرورگر می‌شود.

استفاده از فایل‌های پیکربندی فراداده برای فعال کردن اشتراک‌گذاری اعتبارنامه‌ها.

از iframe های cross-origin استفاده کنید

اگر به دلیل محدودیت‌های دامنه ROR نمی‌توانید از رویکرد فایل‌های پیکربندی فراداده استفاده کنید، عناصر iframe با منشأ متقابل، مسیری قوی و با پشتیبانی استانداردها را برای حل چالش‌های ورود به سیستم بین دامنه‌ای ارائه می‌دهند.

با تعبیه یک مبدا احراز هویت متمرکز (برای مثال، auth.brand.example ) به عنوان یک iframe در یک طرف وابسته (برای مثال، brand.example )، می‌توانید هم با فیلدهای فرم معمول و هم با APIهای مدرن تعامل داشته باشید. برای رمزهای عبور، مدیر اعتبارنامه مرورگر، اقدامات تکمیل خودکار را با مبدا iframe ( auth.example ) مرتبط می‌کند. این به کاربران اجازه می‌دهد تا به طور یکپارچه در سایت‌های مختلف به اعتبارنامه‌های متمرکز خود دسترسی داشته باشند.

برای کلیدهای عبور، پنجره والد باید با استفاده از چارچوب سیاست مجوزها ، به iframe دسترسی بدهد و iframe را قادر سازد تا WebAuthn را برای احراز هویت در برابر شناسه RP مبدا خود فراخوانی کند. در هر دو جریان، CSP (سیاست امنیت محتوا) برای محافظت از کاربران در برابر حملاتی مانند clickjacking و اسکریپت‌نویسی بین سایتی مفید است. پس از موفقیت احراز هویت، جلسه با یک کوکی پارتیشن‌بندی شده برقرار می‌شود و توکن با استفاده postMessage() به طور ایمن به پنجره والد منتقل می‌شود.

• مزایا:
  • اعتبارنامه‌های متمرکز: از چندپارگی اعتبارنامه‌ها جلوگیری می‌کند. یک منبع واحد و متمرکز، هم رمزهای عبور ذخیره شده و هم یک شناسه RP کلید عبور یکپارچه را مدیریت می‌کند و به دامنه‌های مجزا اجازه می‌دهد تا این اعتبارنامه‌ها را بدون نیاز به تجمیع دامنه‌ها به اشتراک بگذارند.
  • احراز هویت زمینه‌ای: کل جریان ورود به سیستم - چه پر کردن خودکار رمز عبور و چه تأیید با کلید عبور - به طور یکپارچه در زمینه صفحه والد اتفاق می‌افتد و از تغییر مسیرهای فدرال مختل‌کننده جلوگیری می‌کند.
  • مقاومت در برابر محافظت در برابر ردیابی: این رویکرد حتی تحت محافظت‌های سختگیرانه ردیابی بین سایتی با استفاده از کوکی‌های پارتیشن‌بندی شده نیز به درستی عمل می‌کند.
• معایب:
  • محدودیت‌های پیاده‌سازی: این معماری نیازمند مهندسی تخصصی است. این معماری نیازمند CSP ( frame-ancestors ) سختگیرانه‌ای برای محدود کردن جاسازی به دامنه‌های والد مورد اعتماد و جلوگیری از کلیک‌ربایی، پیکربندی سیاست‌های مجوزهای HTTP برای فعال کردن WebAuthn API و پیام‌رسانی بین اسنادی امن و معتبر ( postMessage() ) برای کاهش حملات جعل مبدا و CSRF است. بهترین شیوه‌ها را در Passkeys within iframes بیاموزید.

جریان احراز هویت iframe بین مبدائی.

فدراسیون هویت استاندارد را دنبال کنید

اتخاذ فدراسیون هویت استاندارد مانند OpenID Connect یک رویکرد قوی و پایدار برای حفظ سیستم حساب شما است. این رویکرد، گردش کار احراز هویت را با تجمیع آن در یک دامنه اختصاصی ارائه دهنده هویت (IdP)، مانند auth.brand.example ، رسمیت می‌بخشد. با یک پروتکل مشخص، برنامه‌ها کاربران را برای احراز هویت به این مرکز مرکزی هدایت می‌کنند و سپس به طور ایمن انتقال توکن را برای تکمیل ورود به دامنه هدف دریافت می‌کنند. در حالی که اغلب با ورود به سیستم شخص ثالث (مانند ورود با گوگل ) مرتبط است، فدراسیون استاندارد کاملاً معتبر است و به عنوان یک راه حل شخص اول برای جایگزینی راه‌حل‌های شکننده استفاده می‌شود.

• مزایا:
  • زبان مهندسی مشترک: توسعه‌دهندگان نیازی به یادگیری یا نگهداری یک پروتکل خاص و سفارشی ندارند؛ آن‌ها می‌توانند به دانش صنعتی تثبیت‌شده و کتابخانه‌های جامع تکیه کنند. همچنین راه‌حل‌های بسته‌بندی‌شده‌ای نیز وجود دارد.
  • قابلیت اطمینان آزمایش‌شده: پروتکل‌های استاندارد، ایمن و بسیار کمتر از پیاده‌سازی‌های موردی، آزمایش‌شده و کم‌خطر هستند.
  • قابلیت توسعه آسان: اگر سازمان نیاز به ادغام با یک سرویس شخص ثالث جدید یا ادغام یک سرویس خریداری شده در آینده داشته باشد، زیرساخت هویت از قبل برای ارائه اعتبارنامه‌ها مجهز شده است.
  • تجربه کاربری منسجم: کاربران صفحه متمرکز IdP را به عنوان منبع معتبر برند تشخیص می‌دهند و دقیقاً مشخص می‌کنند که چه زمانی و کجا به اطلاعات احراز هویت نیاز است.
• معایب:
  • سربار بالای ادغام: توسعه یا مهاجرت به یک IdP متمرکز، سربار بالای ادغام را ایجاد می‌کند و نیاز به تخصص امنیتی تخصصی دارد. سازمان‌ها باید برای بازسازی ایمن تمام برنامه‌های متصل سرمایه‌گذاری کنند تا از الگوهای مبتنی بر تغییر مسیر ایمن پشتیبانی کنند.
  • ریدایرکت‌های مخرب: جریان احراز هویت مستلزم هدایت کاربران از سایت مبدا به یک صفحه ارائه‌دهنده هویت متمرکز است که از یک تجربه ورود یکپارچه و هماهنگ جلوگیری می‌کند.

جریان استاندارد فدراسیون هویت.

ادغام زیر دامنه‌ها

یک رویکرد ساختاری دیگر، یکپارچه‌سازی تمام دامنه‌ها با انتقال ویژگی‌های دیجیتالی پراکنده به زیر یک دامنه ریشه مشترک قابل ثبت (eTLD+1) است. این امر مستلزم انتقال دامنه‌های جداگانه مانند brand.example و service-app.example به زیر دامنه‌هایی مانند www.brand.example و service.brand.example است.

• مزایا:
  • مدیریت یکپارچه اعتبارنامه‌ها: مدیران رمز عبور می‌توانند دامنه اصلی را تشخیص داده و با تمام زیردامنه‌ها به عنوان یک ورودی واحد رفتار کنند و از تکرار درخواست‌ها و ورود دستی رمزهای عبور جلوگیری کنند.
  • تداوم کلید عبور: توسعه‌دهندگان می‌توانند به‌طور بومی یک شناسه RP کلید عبور را به دامنه قابل ثبت محدود کنند و فوراً پشتیبانی از کلید عبور را در تمام زیردامنه‌های مرتبط گسترش دهند. در این حالت، یک شناسه RP با نام brand.example هم در www.brand.example و هم service.brand.example کار خواهد کرد.
  • اشتراک‌گذاری آسان نشست: یکپارچه‌سازی ساختار دامنه، امکان اشتراک‌گذاری یک نشست واحد را با استفاده از کوکی‌های wildcard فراهم می‌کند (برای مثال، تعیین محدوده یک کوکی به Domain=brand.example ).
• معایب:
  • محدودیت‌های برندسازی و مهاجرت: اگر سازمان شما دامنه‌های سطح بالای متمایز را الزامی کند، این رویکرد می‌تواند محدودیت‌های بالقوه‌ای را برای برندسازی ایجاد کند. این مهاجرت پیچیده است و نیاز به مدیریت دقیق ریدایرکت‌های HTTP و اصلاح گسترده پیکربندی‌های قدیمی بین مبدا دارد.

تجمیع زیر دامنه‌ها تحت یک ریشه مشترک.

نتیجه‌گیری

برای دستیابی به تداوم هویت، باید از یکپارچه‌سازی‌های ورود به سیستم موردی به استانداردهای احراز هویت تثبیت‌شده گذار کنید. با ارزیابی محدودیت‌های کسب‌وکار در برابر این شیوه‌های تثبیت‌شده - مانند فدراسیون، ادغام دامنه، iframeها یا فراداده‌ها - می‌توانید اصطکاک UX را از بین ببرید و احراز هویت را در سراسر اکوسیستم خود بهبود بخشید.

برای کسب اطلاعات بیشتر در مورد موضوعات مرتبط، حتماً وبلاگ ما را دنبال کنید و منابع بیشتری را در پورتال هویت کروم بررسی کنید.