من در حال بررسی برخی از انجمن های مرتبط با مفاهیم امنیتی بودم و موضوعی را پیدا کردم که بسیار رایج است. بسیاری از افراد سردرگمی های خود را در مورد شرایط مربوط به مجوز ، احراز هویت و پروتکل های امنیتی ارسال کرده اند . بنابراین، من فکر کردم چیزی در این مورد به زبان عامیانه بنویسم، که بیشتر به سمت مفهوم باشد و کمتر به جنبه های فنی. قبل از شروع، اجازه دهید به سوالی که واقعا جرقه را در من روشن کرد نگاهی بیندازیم - تفاوت بین OpenID و OAuth چیست ؟ امیدوارم برای شروع با من باشید.
خوب، یکی از اهداف اصلی هر برنامه ای این است که آن را ایمن و آسان برای استفاده بدون تحمیل کار زیادی به کاربر نهایی کند. اکنون، برای تحقق این هدف، باید به چند مورد از جنبه های امنیتی اصلی از نظر پروتکل ها، استفاده و سناریوها توجه کنیم. و این همان چیزی است که این مقاله دارد.
احراز هویت و مجوز چیست؟
به عبارت ساده، احراز هویت فرآیندی است برای تأیید اینکه آیا کاربر کاربر مورد نظر است یا نه هر هویت جعلی. از سوی دیگر، مجوز با دسترسی به منابع سروکار دارد. مجوز نشان می دهد که کاربر می تواند به کدام منابع و تا چه حد دسترسی داشته باشد. بنابراین، در بیشتر برنامهها، هر دو اصطلاح دست در دست هم اجرا میشوند.
Single-Sign-On
SSO یک مکانیسم احراز هویت است که در آن کاربر می تواند با استفاده از نوعی اعتبارنامه به یک برنامه وارد شود و بدون وارد کردن مجدد اعتبار به برنامه دیگری دسترسی پیدا کند. در این سناریو می توان از همان اعتبارنامه ها برای ورود به برنامه دیگری استفاده کرد. بهترین مثال در دنیای واقعی می تواند این باشد - پورتال شرکت داخلی ما که در آن می توانیم پیوندهای بسیاری از برنامه های کاربردی دیگر را پیدا کنیم. بنابراین، هنگامی که وارد پورتال می شویم، برای استفاده از برنامه های دیگر (به غیر از چند برنامه امن تر) نیازی به احراز هویت دوباره و دوباره نداریم.
- مزایای رفتن با SSO بسیار خوشایند است
- یک کاربر باید تنها یک مجموعه از اعتبارنامه ها را به خاطر بسپارد و می تواند با سایر برنامه های مرتبط استفاده شود. حفظ اعتبار در یک مکان باعث صرفه جویی در فضا و همچنین کاهش هزینه می شود
چگونه این SSO را پیاده سازی کنیم؟
در اینجا پروتکل های امنیتی می آیند، یا اصطلاحاتی مانند S AML، OAuth، OpenID ، و غیره. گیج شده اید؟ سرت را خاراندن؟ جای نگرانی نیست. بنشینید و استراحت کنید. ما API های آماده ای برای نجات ما داریم 😊
حال قبل از اینکه مستقیماً وارد کدنویسی شویم، اجازه دهید ابتدا به اصل این اصطلاحات بپردازیم.
OpenID
OpenID برای اهداف احراز هویت استفاده می شود و به ما امکان می دهد از یک حساب موجود برای ورود به سایت های متعدد استفاده کنیم. این توسط یک سازمان غیرانتفاعی به نام بنیاد OpenID تاسیس شد. امروزه این استاندارد باز توسط غول های بسیاری مانند مایکروسافت، گوگل، فیس بوک، AOL و بسیاری دیگر پذیرفته شده است.
چگونه یک حساب OpenID دریافت کنیم؟
گرفتن یک حساب OpenID بسیار ساده است زیرا می توان آن را از طریق هر یک از ارائه دهندگان OpenId (همانطور که در بالا ذکر شد) به دست آورد. هنگامی که حساب به دست آمد، کاربر می تواند به هر وب سایتی که از احراز هویت OpenID پشتیبانی می کند وارد شود . به عنوان مثال، می توانید تصور کنید حساب Blogger.com شما یک شناسه ایمیل Google را برای احراز هویت می پذیرد. در این مثال، Google ارائهدهنده هویت و Blogger.com طرف متکی است . شکل های زیر به شما ایده روشنی در مورد آنچه که ما تازه فهمیدیم به شما می دهد.
![درک مفاهیم - OpenId، OAuth و SAML](http://pezhvak24.ir/dl/10kcor/cscd/article/understanding-concepts-openid-oauth-and-saml/Images/1.png)
لطفاً توجه داشته باشید که همه این ارتباطات به دلیل عامل اعتماد مشترک بین ارائهدهنده هویت و طرف پاسخدهنده، که OpenID است، اتفاق میافتد .
احراز هویت چگونه انجام می شود؟
در ادامه با همین مثال از وب سایت Blogger، کاربر به URL Blogger.com ضربه می زند و در صفحه ورود قرار می گیرد. در آنجا او اعتبار گوگل خود را وارد می کند. پس از آن، درخواست برای تأیید حساب به گوگل رفت. در تأیید موفقیت آمیز توسط Google، کاربر همراه با یک توکن به بلاگر هدایت می شود (به زودی در مورد توکن بحث خواهیم کرد. اما در این مرحله، می توانید آن را به عنوان برچسبی تصور کنید که به Blogger می گوید این کاربر توسط Google تأیید شده است و بلاگر می تواند به او تکیه کنید). از این پس، بلاگر به این نشانه اعتماد می کند و جلسه را برای کاربر آغاز می کند.
OAuth2
OAuth مخفف Open Authorization است و عمدتاً برای دسترسی به نمایندگی از طریق احراز هویت مبتنی بر توکن استفاده می شود. با استفاده از این تفویض دسترسی، یک برنامه کاربردی میتواند از طرف کاربر به منابع موجود در سرور منبع بدون نیاز به وارد کردن مجدد اعتبار دسترسی داشته باشد. این با استفاده از توکن های صادر شده توسط یک ارائه دهنده هویت و با رضایت کاربر به دست می آید. بیایید این را با یک مثال درک کنیم، بگوییم که شما به خارج از شهر می روید و می خواهید دوستتان آلن بماند و از خانه شما مراقبت کند. البته باید کلیدها را به آلن بسپارید. یعنی آلن می تواند وارد خانه شود و به منابع داخل خانه دسترسی پیدا کند. در این قیاس، خانه سرور منبع، آلن مشتری، قفل درب تامین کننده هویت و صاحب خانه کاربر است. منطقی است؟
بیایید روند فکر را کمی تغییر دهیم. در حال حاضر، تا زمانی که من برگردم، آلن در غیاب من خانه را اشغال می کند. یعنی آلن صاحب خانه است. اگرچه فعلاً است، اما هنوز می توان آلن را صاحب خانه در نظر گرفت. این به عنوان شبه احراز هویت نامیده می شود .
اتصال OpenID
برای پیاده سازی یک راه حل امنیتی کامل، هر دو OpenID و OAuth باید با هم باشند. این یکپارچگی به عنوان OpenID Connect نامیده می شود که در آن احراز هویت توسط O p enID و مجوز توسط OAuth2 پشتیبانی می شود .
SAML
SAML مخفف عبارت Security Markup Assertion Language است و یک استاندارد باز برای احراز هویت و مجوز است. از XML برای تمام تراکنشهای خود استفاده میکند تا به ارائهدهندگان هویت اجازه دهد اعتبارنامهها را به ارائهدهندگان خدمات منتقل کنند. در بیشتر سناریوهای دنیای واقعی، ارائه دهندگان هویت و ارائه دهندگان خدمات، موجودیت های کاملاً مجزایی هستند. اکنون، برای اینکه هر دو بر روی مکانیسم SSO کار کنند ، به نوعی مدیریت متمرکز کاربر نیاز است و در اینجا به اظهارات SAML آمده است . سه نوع ادعا وجود دارد:
- احراز هویت: به کاربر می گوید در چه زمانی و با استفاده از چه روشی احراز هویت می شود
- ویژگی: این قطعه داده ای است که اطلاعاتی را در مورد کاربر با برخی ویژگی های خاص ارائه می دهد
- مجوز: به کاربر می گوید که از دسترسی به هر منبعی اعطا یا رد شده است
خلاصه
شرح | OAuth2 | OpenId | SAML |
فرمت نشانه (یا ادعا). | JSON یا SAML2 | JSON | XML |
مجوز؟ | آره | خیر | آره |
احراز هویت؟ | احراز هویت شبه | آره | آره |
سال ایجاد شد | 2005 | 2006 | 2001 |
نسخه فعلی | OAuth2 | اتصال OpenID | SAML 2.0 |
حمل و نقل | HTTP | HTTP GET و HTTP POST | اتصال HTTP Redirect (GET)، اتصال صابون SAML، اتصال HTTP POST و موارد دیگر |
خطرات امنیتی | فیشینگ OAuth 2.0 از امضا، رمزگذاری، اتصال کانال یا تأیید مشتری پشتیبانی نمی کند. در عوض، برای محرمانه بودن کاملاً به TLS متکی است. | ارائهدهندگان هویت فیشینگ گزارشی از ورود به سیستم OpenID دارند که یک حساب در معرض خطر را به نقض حریم خصوصی بزرگتر تبدیل میکند. | XML Signature Wrapping برای جعل هویت هر کاربری |
بهترین مناسب برای | مجوز API | ورود به سیستم برای برنامه های مصرف کننده | ورود به سیستم برای شرکت توجه: برای تلفن همراه مناسب نیست |
اطلاعات اضافی : چرا به OpenId Connect نیاز داریم؟
در حال حاضر، بسیاری از ما قبلاً میدانیم که OAuth 2.0 یک پروتکل مجوز است و با ارائه اطلاعات واقعاً کار بزرگی انجام داده است که به کاربر کمک میکند تا برخی از تصمیمات مجوز شگفتانگیز را اتخاذ کند.
با همه این گونه سوالات به روش های مختلف برخورد می شود زیرا هر ارائه دهنده احراز هویت ابزار خاص خود را برای تبادل این اطلاعات OAuth دارد. از آنجایی که همه ارائهدهندگان سطح امنیت برابری را ارائه نکردهاند، به برخی از وزوزها منجر شد.
در اینجا، OpenID Connect به کمک آمد. تمام مشکلات رایج را با ارائه یک پروتکل احراز هویت با یک روش استاندارد برای تبادل پیام بین ارائه دهنده و مشترکین برطرف می کند، که چیزی جز ترکیبی از OAuth و OpenID نیست.
این را با مثال کد نویسی در یکی از مقالات آینده من شاهد خواهیم بود. تا اون موقع با ما همراه باشید!!!