Single Sign-on یا SSO هنگامی رخ می دهد که کاربر به برنامه ای لاگین می کند و و سپس بدون توجه به سیستم عامل ، فناوری یا دامینی که کاربر از آن استفاده می کند به طور خودکار وارد برنامه های دیگر می شود. به عنوان مثال، اگر به یک سرویس Google مانند Gmail لاگین کنید به طور خودکار در YouTube ، AdSense ، Google Analytics و سایر برنامه های Google احراز هویت می شوید. به همین ترتیب، اگر از Gmail یا سایر برنامه های Google خود Sing out کنید به طور خودکار از همه برنامه ها خارج می شوید که این مورد Single Logout شناخته می شود.


SSO هنگام استفاده از سرویس ها و برنامه ها، تجربه ای یکپارچه را برای کاربران فراهم می کند چرا که برای هر سرویس یا برنامه مجبور به ایجاد چندین Username و Password شوید از یک نام کاربری و پسورد برای لاگین می توانید استفاده کنید. هر زمان که کاربران به دامینی مراجعه کنند که احتیاج به احراز هویت دارد، به دامین authentication یا احراز هویت کننده(redirect) هدایت می شوند و در آنجا ممکن است از آنها خواسته شود log in کنند. اگر کاربر قبلاً در authentication domain لاگین شده باشد، بلافاصله به دامنه اصلی مجددا هدایت شوند.


Single Sign-on و Single Logout از طریق session ها امکان پذیر است. ممکن است حداکثر سه session مختلف برای یک کاربر با SSO وجود داشته باشد:
Local session که توسط برنامه نگهداری و حفظ می شود.
Authorization Server session در صورت فعال بودن SSO
Identity Provider session، اگر کاربر تصمیم به لاگین با استفاده از Identity Provider داشته باشد(مانند Facebook، Google و ...)

با SSO یک دامین مرکزی احراز هویت را انجام می دهد و سپس session را با دامین های دیگر به اشتراک می گذارد. چگونگی Share کردن Session ها ممکن است بین پروتکل های SSO متفاوت باشد، اما مفهوم کلی آن یکسان است.
ساده ترین و ایمن ترین روش برای اجرای Single Sign-on با Auth0 استفاده از Universal Login برای احراز هویت است. در واقع، در حال حاضر SSO فقط در سیستم عامل های iOS یا Android امکان پذیر است(البته برنامه های که درون آنها نصب می کنید هم اگر از Universal Login پشتیبانی کنند پس می توانید SSO را به همین منوال در آنها هم داشته باشید).
برای SSO با Auth0، سرویس مرکزی Auth0 Authorization Server است. بیایید به نمونه ای از جریان SSO در هنگام لاگین کاربر برای اولین بار نگاهی بیندازیم:
در گام نخست application یا برنامه شما به پنجره login هدایت می شود. Auth0 بررسی می کند که آیا کوکی SSO موجود وجود دارد یا خیر. از آنجا که این اولین بار است که کاربر از صفحه لاگین بازدید می کند و هیچ کوکی SSO در آن وجود ندارد از کاربر مانند تصویر زیر خواسته می شود که بر اساس یکی از connection پیکربندی شده در برنامه لاگین را انجام دهد.


هنگامی که کاربر لاگین را انجام می دهد، Auth0 یک کوکی SSO تنظیم کرده و کاربر را به برنامه Redirect می کند و یک شناسه که حاوی اطلاعات هویتی برای کاربر است، برمی گرداند.
حالا بیایید ببینیم وقتی کاربر برای بار دوم قصد لاگین به سرویس یا برنامه ای را دارد، جریان SSO به چه صورتی در حال انجام است:
برنامه کاربر را به صفحه لاگین هدایت می کند. Auth0 بررسی می کند که آیا کوکی SSO موجود وجود دارد یا خیر. Auth0 کوکی SSO را پیدا می کند و در صورت لزوم آن را آپدیت می کند. بدین ترتیب پنجره login به کاربر نمایش داده نمی شود. Auth0 کاربر را به داخل برنامه Redirect می کند و شناسه را که حاوی اطلاعات هویتی کاربر است، برمی گرداند.

SSO از چه پروتکل هایی برای احراز هویت پشتیبانی می کند؟

Web Services Federation & Security Assertion Markup Language

Security Assertion Markup Language یا به اختصار SAML و Web Services Federation یا WS-Fed ر دو پروتکل هایی هستند که به طور گسترده ای در پیاده سازی SSO استفاده می شوند. SAML و WS-Fed داده های authorization و authentication را در فرمت XML تبادل می کنند. بخشهای اصلی این تبادل، User و identity provider و service provider است.
با SAML یا WS-Fed:
کاربر منبع یا resource ای را از service provider درخواست می کند.
service provider با identity provider بررسی می کند آیا کاربر مجاز به دسترسی به منبعی است یا خیر.
identity provider باید هویت کاربر را تایید کند و در صورت معتبر بودن هویت، به service provide اعلام می کند کاربر امکان دسترسی دارد.

OpenID Connect

OpenID Connect یا OIDC یک پروتکل احراز هویت است که معمولاً در پیاده سازی SSO consumer-facing SSO مورد استفاده قرار می گیرد.
با OIDC:
کاربر درخواست دسترسی به یک برنامه را می دهد.
این برنامه کاربر را برای تأیید اعتبار به identity provider هدایت می کند.
identity provider در صورتی که هویت کاربر را تصدیق و تایید کند به کاربر Prompt می دهد که می تواند از اطلاعات برنامه استفاده کند. در صورتی که دسترسی به کاربر تایید شده اعطا شود، identity provider یک شناسه تولید می کند که حاوی اطلاعات هویتی کاربر است و برنامه می تواند از آن استفاد کند.
در آخر identity provider کاربر را به برنامه بر می گرداند.

AD/LDAP

Lightweight Directory Access Protocol یا LDAP یک application protocol است که برای دسترسی به فهرست credential هایی که توسط یک یا چند برنامه قابل استفاده است. این پروتکل مناسب شبکه های LAN یا اینترانت است. هنگامی که با Active Directory (AD) جفت می شود، LDAP مکانی متمرکز برای هویت کاربر فراهم می کند، بنابراین برنامه درخواست تأیید اعتبار را به سرور LDAP / AD هدایت می کند. پروتکل LDAP اطلاعات در فرمت LDIF تبادل می کند.

Inbound SSO

برای inbound SSO، Auth0 در واقع SSO provider است.
وقتی کاربر به application ای لاگین می کند:
این برنامه یک یا چند identity provider خارجی یا external را به کاربر پیشنهاد می دهد.
کاربر identity provider را برای لاگین به برنامه انتخاب می کند. با احراز هویت موفقیت آمیز، کاربر به برنامه بازمی گردد.

Outbound SSO

برای outbound SSO یک identity provider جانبی یا Third-party در واقع SSO provider است.
وقتی کاربر به برنامه یا application ای لاگین می کند:
این برنامه کاربر را به یک identity provider هدایت می کند.
third-party identity provider فرآیند authentication و authorization را انجام می دهد.
هنگام برنامه ریزی برای اجرای outbound SSO می توانید SSO Dashboard Extension را برای استفاده انتخاب کنید که به شما امکان می دهد داشبوردی ایجاد کنید تا چندین برنامه سازمانی را که می توانند با SSO فعال شده و کار کنند را لیست کنید. سپس این داشبورد برای لاگین کاربران ارائه می شود.

همانطور که از توضیحات مطالب مشخص است، چه در بیزینس و کسب و کارها و هم در زمینه ای شخصی، SSO فرآیند احراز هویت را بسیار ساده و سریع می کند. بدون نیاز به داشتن چندین Credential برای سرویس ها و برنامه های مختلف تنها با داشتن یک Credential و کمک از Sigle Sign on می توانند به سرویس های مورد نظر لاگین کنند و از آن استفاده کنند.