رکورد تصمیم معماری: گزینه‌های احراز هویت و مجوزدهی

احراز هویت و مجوزدهی در برنامه‌های وب دو مفهوم حیاتی برای ایمن‌سازی دسترسی به برنامه‌ها و سرویس‌ها هستند. هر دو به هویت کاربران و نحوهٔ اعطای مجوزها مربوط می‌شوند، اما بر جنبه‌های متفاوتی تمرکز دارند:

احراز هویت (Authentication) فرایند راستی‌آزمایی هویت یک کاربر یا سیستم است.
مجوزدهی (Authorization) فرایند تعیین این است که کاربر یا سیستم احراز هویت‌شده به کدام منابع یا اقدامات دسترسی دارد.

اکنون بیایید به پروتکل‌ها و فناوری‌های مشخصی که نام برده‌اید و معمولاً در برنامه‌های وب مدرن برای مدیریت احراز هویت و مجوزدهی به کار می‌روند بپردازیم.

1. OAuth (Open Authorization)

OAuth یک استاندارد باز برای مجوزدهی است. به کاربر اجازه می‌دهد بدون اشتراک‌گذاری اعتبارنامه‌های خود، به یک برنامهٔ شخص ثالث دسترسی محدود به منابعش بدهد. ایدهٔ اصلی دسترسی تفویض‌شده (delegated access) است. OAuth اغلب در موقعیت‌هایی به کار می‌رود که کاربران می‌توانند بدون دادن مستقیم نام کاربری و گذرواژه به شخص ثالث، به یک سرویس شخص ثالث وارد شوند (مثلاً ورود با Google).

جریان (Flow): OAuth معمولاً از جریانی مبتنی بر توکن پیروی می‌کند، که در آن یک سرور مجوزدهی یک توکن دسترسی به برنامهٔ شخص ثالث صادر می‌کند. این توکن مجوزهای کاربر را نمایندگی می‌کند و برنامه از آن برای دسترسی به داده‌ها یا منابع کاربر از یک API استفاده می‌کند.
نمونه: کاربری با حساب Google خود وارد یک برنامهٔ شخص ثالث می‌شود. Google هویت کاربر را راستی‌آزمایی می‌کند و سپس توکنی می‌دهد که به برنامهٔ شخص ثالث اجازه می‌دهد به برخی داده‌های Google (مثلاً Google Calendar) دسترسی یابد.

OAuth احراز هویت را مستقیماً مدیریت نمی‌کند؛ مربوط به اعطای دسترسی است. برای احراز هویت، OAuth اغلب با پروتکل‌های دیگری مانند OpenID Connect جفت می‌شود.

2. OpenID Connect (OIDC)

OpenID Connect (OIDC) لایهٔ هویتی است که روی OAuth 2.0 ساخته شده و احراز هویت را به قابلیت‌های مجوزدهی OAuth اضافه می‌کند. در اصل، OpenID Connect، OAuth را گسترش می‌دهد تا احراز هویت کاربر را مدیریت کند و روشی استاندارد برای برنامه‌ها جهت راستی‌آزمایی هویت کاربر فراهم می‌کند.

جریان (Flow): وقتی کاربر با OpenID Connect وارد می‌شود، برنامهٔ شخص ثالث (علاوه بر توکن دسترسی OAuth) یک توکن ID درخواست می‌کند. توکن ID حاوی اطلاعاتی دربارهٔ کاربر (مانند نام کاربری، ایمیل و سایر claimها) است. این به برنامه امکان می‌دهد بداند کاربر کیست و آیا احراز هویت شده است.
نمونه: ورود به سرویسی مانند Slack با حساب Google (که Google ارائه‌دهندهٔ OpenID Connect است) شامل احراز هویت از طریق OpenID Connect است، در حالی که OAuth دسترسی به منابع Google شما را مدیریت می‌کند.

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

3. SAML (Security Assertion Markup Language)

SAML استانداردی قدیمی‌تر و مبتنی بر XML است که برای تبادل داده‌های احراز هویت و مجوزدهی میان طرف‌ها، به‌ویژه در سناریوهای ورود یکپارچه (SSO)، به کار می‌رود. عمدتاً در محیط‌های سازمانی استفاده می‌شود تا کاربران بتوانند یک‌بار احراز هویت شوند و بدون وارد کردن مجدد اعتبارنامه‌ها به چندین برنامه دسترسی یابند.

جریان (Flow): کاربر ابتدا نزد یک ارائه‌دهندهٔ هویت (IdP) احراز هویت می‌شود. IdP یک ادعای SAML (assertion) امضاشده تولید می‌کند که شامل هویت کاربر و ویژگی‌های مرتبط است. این ادعا برای ارائه‌دهندهٔ سرویس (SP) فرستاده می‌شود که از آن برای مجوزدهی دسترسی به برنامه استفاده می‌کند.
نمونه: کارمندی وارد پورتال شرکتی خود (IdP) می‌شود و بدون وارد کردن مجدد اعتبارنامه‌ها به‌طور خودکار به سیستم‌های دیگری مانند ایمیل، CRM و غیره وارد می‌شود. فرایند احراز هویت بر پایهٔ ادعای SAML ارسالی توسط IdP است.

SAML معمولاً در راه‌حل‌های SSO سازمانی به کار می‌رود و برای برنامه‌های وب در محیط‌های شرکتی خوب عمل می‌کند، اما در مقایسه با OAuth/OIDC برای موبایل مناسب‌تر نیست.

4. WS-Federation (Web Services Federation)

WS-Federation پروتکل دیگری برای ورود یکپارچه (SSO) است، به‌ویژه در محیط‌های سازمانی مبتنی بر Microsoft. بخشی از خانوادهٔ مشخصات WS- (Web Services)* است و فدراسیون هویت در دامنه‌های امنیتی مختلف (مثلاً میان سازمان‌های مختلف یا میان سرویس‌های مختلف) را ممکن می‌کند.

جریان (Flow): WS-Federation به یک ارائه‌دهندهٔ هویت مورد اعتماد (IdP) اجازه می‌دهد کاربران را احراز هویت کند و توکن‌هایی صادر کند که ارائه‌دهندهٔ سرویس می‌تواند برای مجوزدهی به کار ببرد. شبیه SAML است اما اغلب در موقعیت‌هایی به کار می‌رود که به فناوری‌های Microsoft وابستگی زیادی دارند.
نمونه: کاربری وارد یک برنامهٔ سازمانی میزبانی‌شده در Microsoft Azure Active Directory (AD) می‌شود و هویت او می‌تواند برای دسترسی به سایر سرویس‌های فدره، از جمله برنامه‌های میزبانی‌شده توسط تأمین‌کنندگان شخص ثالث، به کار رود.

هرچند در بسیاری از محیط‌های وب مدرن، پروتکل‌های جدیدتری مانند OAuth2.0 و OpenID Connect تا حد زیادی جای WS-Federation را گرفته‌اند، هنوز در سیستم‌های قدیمی، به‌ویژه در سازمان‌های Microsoft‌محور، به کار می‌رود.

5. LDAP (Lightweight Directory Access Protocol)

LDAP پروتکلی برای دسترسی و مدیریت خدمات دایرکتوری است که معمولاً برای ذخیرهٔ اعتبارنامه‌های کاربران و مدیریت کنترل دسترسی در یک دایرکتوری متمرکز (که اغلب سرویس دایرکتوری نامیده می‌شود) به کار می‌رود. LDAP به‌طور مشخص دربارهٔ احراز هویت یا مجوزدهی نیست اما برای ذخیره و بازیابی داده‌های هویتی به کار می‌رود که سپس در آن فرایندها استفاده می‌شوند.

احراز هویت: LDAP به یک برنامه اجازه می‌دهد با پرس‌وجو از سرویس دایرکتوری برای اعتبارنامه‌ها (مانند گذرواژه‌ها) کاربران را احراز هویت کند.
مجوزدهی: نقش‌ها و مجوزهای کاربر را نیز مدیریت می‌کند و به تعیین اینکه آیا کاربر به منابع مشخصی دسترسی دارد کمک می‌کند.
نمونه: بسیاری از سازمان‌ها برای احراز هویت و مجوزدهی از دایرکتوری‌های مبتنی بر LDAP (مثلاً Active Directory) استفاده می‌کنند، به‌ویژه در محیط‌های Windows.

LDAP برای مدیریت دسترسی کاربران در سیستم‌های داخلی سازمان‌ها حیاتی است، اما در بافت وب مدرن، LDAP اغلب برای مدیریت هویت کامل‌تر با پروتکل‌های دیگری مانند SAML یا OAuth ادغام می‌شود.

6. ارائه‌دهندگان SSO اجتماعی

ارائه‌دهندگان ورود یکپارچه (SSO) اجتماعی مانند Facebook، Google، Twitter، GitHub و دیگران به کاربران اجازه می‌دهند با اعتبارنامه‌های شبکهٔ اجتماعی خود به برنامه‌های شخص ثالث وارد شوند. این نوعی احراز هویت مبتنی بر OAuth است که در آن سرویس شخص ثالث (مثلاً Google) ارائه‌دهندهٔ هویت است.

جریان (Flow): کاربر (مثلاً) روی «ورود با Google» کلیک می‌کند. برنامه به Google هدایت می‌کند و کاربر در آنجا وارد می‌شود (اگر قبلاً وارد نشده باشد). سپس Google یک توکن دسترسی یا توکن ID به برنامهٔ شخص ثالث می‌دهد که می‌تواند برای احراز هویت کاربر و احتمالاً دسترسی به داده‌های او به کار رود.
نمونه: بسیاری از برنامه‌ها به شما اجازه می‌دهند با اعتبارنامه‌های Google یا Facebook وارد شوید. برنامه در پشت صحنه از OAuth یا OpenID Connect برای راستی‌آزمایی هویت شما و، در برخی موارد، دسترسی به برخی داده‌های شبکهٔ اجتماعی استفاده می‌کند.

SSO اجتماعی روشی راحت و پرکاربرد برای احراز هویت است زیرا اصطکاک را برای کاربرانی که شاید نخواهند یک نام کاربری و گذرواژهٔ دیگر بسازند کاهش می‌دهد.

خلاصهٔ تفاوت‌ها:

OAuth: برای مجوزدهی به کار می‌رود و به برنامه‌های شخص ثالث اجازه می‌دهد بدون افشای اعتبارنامه‌ها به داده‌های کاربر دسترسی یابند.
OpenID Connect: OAuth را گسترش می‌دهد تا احراز هویت فراهم کند و به برنامه‌ها امکان می‌دهد هویت کاربر را راستی‌آزمایی کنند.
SAML: پروتکل مبتنی بر XML که برای SSO، اغلب در محیط‌های سازمانی، به کار می‌رود.
WS-Federation: پروتکل ویژهٔ Microsoft برای فدراسیون هویت که در سیستم‌های قدیمی استفاده می‌شود.
LDAP: پروتکلی برای پرس‌وجو از سرویس‌های دایرکتوری جهت احراز هویت کاربران و مدیریت مجوزدهی.
ارائه‌دهندگان SSO اجتماعی: سیستم‌های مبتنی بر OAuth (مانند Google، Facebook) که به برنامه‌های شخص ثالث اجازه می‌دهند کاربران را با اعتبارنامه‌های شبکهٔ اجتماعی‌شان احراز هویت کنند.

هر یک از این فناوری‌ها نقاط قوت و موارد استفادهٔ خود را دارد و در برنامه‌های مدرن ممکن است ترکیبی از آن‌ها را برای جنبه‌های مختلف امنیت ببینید (مثلاً OAuth/OIDC برای دسترسی API، SAML برای SSO سازمانی).