احراز هویت را به یک ارائه‌دهنده identity provider واگذار کنید. این می‌تواند توسعه را ساده‌تر کند، نیاز به مدیریت کاربر را به حداقل برساند و تجربه کاربری برنامه را بهبود بخشد. زمینه و مشکل کاربران معمولاً نیاز به کار با چندین برنامه دارند که توسط سازمان‌های مختلفی که با آنها رابطه تجاری دارند، ارائه و میزبانی می‌شوند. ممکن است از این کاربران خواسته شود که از اعتبارنامه‌های (credentials) خاص و متفاوت برای هر یک استفاده کنند. این کار می‌تواند: باعث ایجاد یک تجربه کاربری ناخوشایند شود به‌خصوص هنگامی که کاربران دارای اعتبارنامه‌های مختلف هستند، اغلب sign-in credentials به سیستم را فراموش می‌کنند. آسیب‌پذیری‌های امنیتی را افزایش دهد. هنگامی که یک کاربر شرکت را ترک می‌کند، حساب کاربری او باید فوراً لغو شود و نادیده‌گرفتن این موضوع در سازمان‌های بزرگ آسان است. پیچیده کردن user management. در واقع Administrators باید credentials را برای همه کاربران مدیریت کنند و کارهای اضافی مانند ارائه یادآوری رمز عبور را انجام دهند. کاربران معمولاً ترجیح می‌دهند از اعتبار (credentials) یکسانی برای همه این برنامههای استفاده کنند.
یک مکانیزم احراز هویت را پیاده‌سازی کنید که می‌تواند از هویت فدرال (federated) استفاده کند. احراز هویت کاربر را از کد برنامه جدا کنید و احراز هویت را به یک ارائه‌دهنده هویت قابل‌اعتماد واگذار کنید. این می‌تواند توسعه را ساده کند و به کاربران اجازه دهد تا با استفاده از طیف وسیع‌تری از ارائه‌دهندگان هویت (IdP) احراز هویت کنند و درعین‌حال هزینه‌های اداری را به حداقل برساند. همچنین به شما این امکان را می‌دهد که به‌وضوح احراز هویت (authentication) را از مجوز (authorization) جدا کنید. ارائه‌دهندگان هویت مورداعتماد شامل دایرکتوری‌های شرکتی، سایر سرویس‌های توکنهای امنیتی (security token services (STS)) ارائه‌شده توسط شرکای تجاری یا ارائه‌دهندگان هویت social identity هستند که می‌توانند کاربرانی را که مثلاً دارای حساب کاربری Microsoft، Google، Yahoo! یا Facebook هستند، احراز هویت کنند. لازم به ذکر است که دایرکتوری‌های شرکتی یا Corporate directories که به آن 'دایرکتوری‌های الکترونیکی' نیز گفته می‌شود، نوع تخصصی پایگاه‌داده‌ای هستند که حاوی اطلاعات مرتب شده از کارکنان به‌صورت سلسله‌مراتبی در یک سازمان یا یک شرکت است. شکل زیر الگوی هویت فدرال (Federated Identity) را در زمانی که یک client application نیاز به دسترسی به سرویسی دارد که باید احراز هویت شود را نشان می‌دهد. احراز هویت توسط یک identity providers (IdP) که در هماهنگی با security token services (STS) کار می‌کند انجام می‌شود. IdP توکنهای امنیتی صادر می‌کند که اطلاعاتی در مورد کاربر تأیید شده ارائه می‌کند. این اطلاعات که به‌عنوان claims نامیده می‌شود، شامل هویت کاربر است و همچنین ممکن است شامل اطلاعات دیگری مانند role membership و granular access دقیق‌تر باشد.
این مدل اغلب claims-based access control نامیده می‌شود. برنامه‌ها و سرویس‌ها بر اساس موارد موجود در توکن، اجازه دسترسی به ویژگی‌ها و اجرای عملیات‌ها را می‌دهند. سرویسی که نیاز به احراز هویت دارد باید به IdP اعتماد کند. برنامه مشتری با IdP که احراز هویت را انجام می‌دهد تماس می‌گیرد. اگر احراز هویت موفقیت‌آمیز باشد، IdP یک توکن حاوی claims که کاربر را به STS شناسایی می‌کند، برمی‌گرداند (توجه داشته باشید که IdP و STS می‌توانند یک سرویس باشند). STS می‌تواند claimهای موجود در توکن را بر اساس قوانین از پیش تعریف شده، قبل از بازگرداندن آن به client، تبدیل و تکمیل کند. سپس برنامه کلاینت می‌تواند این نشانه را به‌عنوان اثبات هویت خود به سرویس ارسال کند.
ممکن است STS یا security token services اضافی در دنباله‌ای از اعتمادها وجود داشته باشد. به‌عنوان‌مثال، در سناریویی که بعداً توضیح داده شد، یک STS داخلی به STS دیگری اعتماد می‌کند که مسئول دسترسی به یک identity provider برای احراز هویت کاربر است. این رویکرد در سناریوهای سازمانی که در آن on-premises STS و directory وجود دارد رایج است.
احراز هویت فدرال (Federated authentication) راه‌حلی مبتنی بر استانداردها را برای مسئله اعتماد به هویت (trusting identities) در دامنه‌‌های مختلف ارائه می‌دهد و می‌تواند از یک ورود به سیستم پشتیبانی کند. این نوع احراز هویت در همه انواع برنامه‌ها، به‌ویژه برنامههای میزبانی شده در فضای ابری رایج‌تر می‌شود، زیرا از یک ورود بدون نیاز به اتصال مستقیم شبکه به ارائه‌دهندگان هویت پشتیبانی می‌کند. کاربر مجبور نیست برای هر برنامه‌ای اعتبارنامه را وارد کند. این امر امنیت را افزایش می‌دهد؛ زیرا از ایجاد اعتبار موردنیاز برای دسترسی به بسیاری از برنامههای مختلف جلوگیری می‌کند و همچنین اعتبار کاربر را از همه افراد به جز ارائه‌دهنده هویت اصلی پنهان می‌کند. برنامههای فقط اطلاعات هویت احراز هویت شده موجود در توکن را می‌بینند.
هویت فدرال (Federated identity) همچنین دارای این مزیت عمده است که مدیریت هویت و اعتبار را به عهده identity provider می‌گذارد. برنامه یا سرویس نیازی به ارائه ویژگی‌‌های مدیریتی provide identity ندارد. علاوه بر این، در سناریوهای شرکتی، دایرکتوری شرکت در صورت اعتماد به identity provider، نیازی به اطلاع از کاربر ندارد. این کار تمام سربار اجرایی مرتبط به مدیریت هویت کاربر را حذف می‌کند.
احراز هویت (Authentication) می‌تواند تنها یک نقطه شکست باشد. اگر application خود را بر روی چندین دیتاسنتر مستقر می‌کنید، سازوکار مدیریت هویت (identity management) خود را در دیتاسنتر یکسانی برای حفظ قابلیت اطمینان و دردسترس‌بودن برنامه در نظر بگیرید.
ابزارهای Authentication ممکن است سطح دسترسی قابل تنظیمی را روی نقش‌‌های موجود در authentication token را ممکن سازند که اغلب به‌عنوان role-based access control (RBAC) نامیده می‌شود و می‌تواند سطح دقیق‌تری از کنترل دسترسی به ویژگی‌ها و منابع را فراهم کند.
بر خلاف دایرکتوری شرکتی که معمولاً claims-based authentication با استفاده از social identity providers اطلاعات بیشتری در مورد کاربر احراز هویت شده به نسبت روش‌‌های دیگر مثلاً احراز هویت فقط با email address نمی‌دهد. برخی از social identity providers مثل Microsoft account فقط یک identifier یکتا تولید می‌کنند. برنامه معمولاً باید برخی از اطلاعات کاربران ثبت‌نام‌شده را حفظ کند و بتوانید این اطلاعات را با شناسه موجود در token مطابقت دهید. معمولاً این کار از طریق ثبت‌نام(registration) انجام می‌شود، زمانی که کاربر برای اولین‌بار به برنامه دسترسی پیدا می‌کند، و اطلاعات پس از هر بار احراز هویت به‌عنوان claims اضافی به توکن تزریق می‌شود.
اگر بیش از یک identity provider برای STS تنظیم شده باشد STS باید تعیین کند که identity provider کاربر باید برای تأیید اعتبار (authentication) به آن redirected شود. این فرایند Discovery Home Realm نامیده می‌شود. STS ممکن است بتواند این کار را به طور خودکار بر اساس آدرس ایمیل یا نام کاربری که کاربر ارائه می‌دهد، انجام دهد، subdomain برنامه‌ای که کاربر به آن دسترسی دارد دارای دامنه آدرس IP کاربر یا محتوای یک کوکی ذخیره شده در کاربر مرورگر است به‌عنوان‌مثال، اگر کاربر آدرس ایمیل را در دامنه مایکروسافت مانند [email protected] وارد کند، STS کاربر را به صفحه ورود به‌حساب مایکروسافت هدایت می‌کند. در بازدیدهای بعدی، STS می‌تواند از یک کوکی استفاده کند تا نشان دهد آخرین علامت ورود به‌حساب مایکروسافت بود. اگر Discovery Automatic نتواند home realm را تعیین کند، STS یک صفحه Discovery Realm Home را نشان می‌دهد که identity provider قابل‌اعتماد را لیست می‌کند و کاربر باید گزینه موردنظر را انتخاب کند.
این الگو برای سناریوهایی مانند حالت‌های زیر مناسب هست:
در حالت Single sign-on یا به‌اختصار SSO.
در این سناریو شما باید افراد را برای اپلیکیشن‌‌های شرکتی که در فضای ابری خارج از مرزهای امنیتی شرکت میزبانی می‌شوند، احراز هویت کنید، بدون اینکه هر بار که از برنامه‌ای بازدید می‌کنند مجبور به ورود به سیستم شوند. تجربه کاربر مانند استفاده از برنامههای داخلی سازمان است که در آن هنگام ورود به شبکه شرکتی احراز هویت می‌شوند و ازآن‌پس بدون نیاز به ورود مجدد به همه برنامههای مربوطه دسترسی دارند.
در حالت تعیین هویت فدرال با شرکای متعدد.
در این سناریو شما باید هم کارمندان شرکت و هم شرکای تجاری را که حسابی در فهرست شرکتی ندارند، احراز هویت کنید. این امر در اپلیکیشن‌‌های تجاری و در کسب‌وکارهای (business-to-business) رایج است، برنامه‌‌هایی که با سرویس‌های شخص ثالث یکپارچه می‌شوند و شرکت‌‌هایی با سیستم‌‌های فناوری اطلاعات مختلف ادغام یا منابع مشترک را به اشتراک گذاشته‌اند.
در حالت تعیین هویت فدرال در برنامههای SaaS.
در این سناریو، فروشندگان نرم‌افزار مستقل (independent software vendors) یک سرویس آماده برای استفاده برای چندین مشتری ارائه می‌دهند. هر مشتری با استفاده از identity provider مناسب تأیید می‌شود. به‌عنوان‌مثال، کاربران تجاری از اعتبار شرکت‌های خود استفاده می‌کنند، درحالی‌که مصرف‌کنندگان و مشتریان از اعتبار هویت اجتماعی خود استفاده می‌کنند.
این الگو ممکن است در شرایط زیر مفید نباشد:
همه کاربران application می‌توانند توسط یک identity provider احراز هویت شوند و هیچ نیازی به احراز هویت با استفاده از identity provider دیگر وجود ندارد. این امر در برنامههای تجاری که از دایرکتوری شرکتی (قابل‌دسترسی در برنامه) برای احراز هویت، با استفاده از VPN یا (در سناریوی میزبان ابری) از طریق یک اتصال شبکه مجازی بین دایرکتوری داخلی و برنامه استفاده می‌کنند، معمول است.
این برنامه در ابتدا با استفاده از مکانیزم احراز هویت متفاوت ساخته شد. اضافه‌کردن claims-based authentication و کنترل سطح دسترسی به برنامههای موجود از قبل می‌تواند پیچیده باشد و احتمالاً مقرون‌به‌صرفه نیست.
یک organization hosts یک نرم‌افزار multi-tenant به‌عنوان software as a service (SaaS) در Microsoft Azure است. این برنامه شامل وب‌سایتی است که کلاینت‌ها می‌توانند از آن برای مدیریت برنامه برای کاربران خود استفاده کنند. این برنامه به کاربران اجازه می‌دهد تا با استفاده از هویت فدرال که توسط Active Directory Federation Services یا به‌اختصار AD FS تولید می‌شود، به وب‌سایت موردنظر دسترسی پیدا کنند.
شکل بالا نشان می‌دهد که چگونه کاربرها با identity provider خود احراز هویت می‌کنند (مرحله ۱)، در این مورد AD FS. پس از احراز هویت موفق کاربرها، AD FS یک توکن صادر می‌کند. مرورگر کاربر این نشانه را به ارائه‌دهنده فدراسیون برنامه SaaS که به توکنهای صادر شده توسط AD FS مستأجر اعتماد می‌کند، می‌فرستد تا رمزی را که برای SaaS federation provide معتبر است، پس بگیرد (مرحله ۲). در صورت لزوم، SaaS federation provide قبل از بازگرداندن رمز یا توکن جدید به مرورگر کلاینت، claims موجود در توکن را به claims که برنامه تشخیص می‌دهد (مرحله ۳) انجام می‌دهد. برنامه به توکنهای صادر شده توسط SaaS federation provide اعتماد می‌کند و از claims موجود در توکن برای اعمال قوانین مجوز استفاده می‌کند (مرحله ۴). کاربرها و Tenantها(رجوع به مقدمه) برای دسترسی به برنامه، نیازی به‌خاطر سپردن اعتبارنامه‌های(credentials) جداگانه ندارند و administrator می‌تواند لیست کاربرانی را که می‌توانند به برنامه دسترسی داشته باشند در ADFS خودپیکربندی کند.