درباره OAuth2 – Virgol بیاموزید

پیش نوشت: این مقاله برای نوشتن بسیار ساده است ، بنابراین اگر اطلاعات اساسی در مورد OAuth2 دارید ، پیشنهاد می کنم این مقاله را پرش کنید و پست های زیر را بخوانید. (البته هنوز نوشته نشده اند. در آینده لینک ها در همان متن خواهند بود.)

در اکثر سیستمهایی که ما به عنوان توسعه دهنده پیاده سازی می کنیم ، منابع به دو بخش کلی تقسیم می شوند.

• دسته اول منابع رایگان است. منابع رایگان یا عمومی منابعی هستند که همه کاربران می توانند به آنها دسترسی پیدا کنند ، مانند صفحه تماس با ما ، صفحه محصول تجارت الکترونیکی و غیره.
• دسته دوم منابع حفاظت شده است. این بدان معنی است که سیستم باید کاربر را شناسایی کرده و صحت آن را تأیید کند تا ببیند آیا کاربر می تواند به این منبع دسترسی داشته باشد یا خیر. مانند تمام صفحات پنل مدیریت فروشگاه.

نکته: این منبع به قسمت های مختلف سیستم اشاره دارد که می تواند یک صفحه از یک سایت یا API برای نقطه انتهایی باشد.

همانطور که گفتم برای دستیابی به منابع غیر دولتی باید کاربر مشخص شود. به طور کلی ، کاربر در دو مرحله تعریف می شود:

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

تاکنون هیچ کس نتوانسته است راه حل کامل ارسال کند و عجیب نیست. سیستم شما همچنین حاوی صفحات کلی است که نیازی به ورود کاربر ندارد و منابعی دارد که کاربر باید آن را انتخاب و تأیید کند.

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

بیایید نگاهی به چند راه حل که به ذهن متبادر می شود بیاندازیم:

اطلاعات کاربر (نام کاربری و رمز عبور) که کاربر در سایت ما ثبت کرده است ، همان اطلاعات کاربری است که از اینستاگرام استفاده می کند. در نتیجه ، پس از ورود کاربر به سایت ما ، ما همان اطلاعات کاربر را به API اینستاگرام ارسال می کنیم و کدی را دریافت می کنیم که نشانگر مجوز ما است. سرانجام ، از این لحظه به بعد ، سیستم ما به عنوان مشتری حق دارد به تمام منابعی که کاربر واقعی در منابع حفاظت شده دارد ، دسترسی داشته باشد.

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

مشکل بعدی این است که مشتری پس از دریافت نشانه دسترسی به کلیه دسترسی های اختصاص یافته به کاربر ، که منشأ همان کلاهبرداری هویتی است.

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

کاربر اطلاعات کاربری خود را در اینستاگرام در اختیار شما قرار می دهد! این بدان معنی است که احتمال سوءاستفاده از اطلاعات محرمانه کاربر 100٪ افزایش یافته است. مشتری می تواند اطلاعات کاربر وارد شده را در جایی ذخیره کند و بعداً از آن استفاده کند. از همه مهمتر ، کاربر راهی برای محافظت از اطلاعات اینستاگرام خود ندارد مگر اینکه رمز ورود اینستاگرام خود را تغییر دهید!

اما ما هنوز به عمق فاجعه نرسیده ایم. این مسئله هنگامی خطرناک تر می شود که ما از سیستم رمزگذاری مشترک برای سیستم های مختلف استفاده می کنیم. در نتیجه ، در سیستمی که طراحی می کنیم ، نه تنها رمز عبور کاربر را در اینستاگرام خود داریم بلکه می توانیم این رمز عبور را در سیستم های دیگر مانند ایمیل ، سیستم بانکی و غیره نیز تأیید کنیم (ممکن است کاربر ما یکی از آن دسته افرادی باشد که رمز عبور را دارد برای همه خدمات آنها.)

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

جالب است بدانید که این روش قبل از ورود OAuth استفاده شده است.

در این روش ، اینستاگرام یک کلید API را به مشتری اختصاص می دهد. هر وقت مشتری می خواهد آخرین ارسال های کاربر را از اینستاگرام دریافت کند ، وی این کلید API را با درخواست ارسال می کند. اگر کلید فرستنده مشتری معتبر باشد ، اینستاگرام به درخواست پاسخ می دهد ، در غیر این صورت مشتری اخطار مسدود شده را دریافت می کند.

ضرر اصلی این روش این است که مشتری تأیید می شود و کاربر نیست! بنابراین مشتری می تواند از کاربرانی که هنوز وارد سیستم نشده اند از اینستاگرام اطلاعاتی را درخواست کند.

توجه: درست است که این روش برای سناریوی مورد نظر ما کاملاً اشتباه است ، اما کاربرد خاص خود را دارد و در سیستم هایی مانند Google Map و غیره استفاده می شود.

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

• کاربر باید درخواستی از اینستاگرام داشته باشد.
• نشانه را بگیرید و در جایی ذخیره کنید.
• به خدمات ما وارد شوید و این نشانه را برای ما ارسال کنید

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

در این مرحله OAuth معرفی شد و ما نسخه نهایی OAuth2 را با هم مرور می کنیم.

OAuth2 یک پروتکل امنیتی است که از چندین مؤلفه تشکیل شده است. هر یک از این مؤلفه ها نقش ایفا می کنند ، اما در نهایت ، این اتصال دسترسی کاربر از یک سرویس به سرویس دیگر را منتقل می کند.

بیایید ابتدا به مواد تشکیل دهنده با هم نگاه کنیم:

• مشتری: خدمتی است که قرار است از خدمات دیگری استفاده کند. در مثال ما می توانستیم سایت خود را پیاده سازی کنیم که قرار است از بسیاری از خدمات اینستاگرام استفاده کند.
• صاحب منبع یا مؤلفه کاربر: کاربرانی که به منابع حفاظت شده دسترسی دارند. در مثال ما ، یک کاربر دارای یک حساب کاربری اینستاگرام است و می خواهد بخشی از دسترسی خود را به خدمات ما ارائه دهد.
• مؤلفه منابع حفاظت شده: منابعی که برای دسترسی به آنها مجوز لازم را داریم. در مثال ما ، اطلاعات حساب کاربر کاربر Instagram.
• مؤلفه تأیید هویت سرور: مؤلفه ای که درخواست های تولید ، ورود به سیستم و نشانه ها را کنترل می کند.

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

به طور کلی ، ما می توانیم فرایند OAuth2 را به دو مرحله اصلی تقسیم کنیم:

• مرحله 1: دسترسی را دریافت کنید
• مرحله 2: برای دسترسی به منابع محافظت شده از این Access_token استفاده کنید

در نمودار زیر ، این دو مرحله را با جزئیات بیشتری نشان داده ایم.

1. در مرحله اول ، کاربر به مشتری اطلاع می دهد که قصد دارد با استفاده از سرویس در نظر گرفته شده ، که اینستاگرام است ، وارد سیستم شوید.

2. مشتری کاربر را به صفحه ورود به سیستم خدمات اصلی هدایت می کند. در این صفحه ، علاوه بر ورود به سیستم ، کاربر باید به سرور تأیید اعتبار اطلاع دهد که قصد دارد یک سری از دسترسی ها را به مشتری درخواست شده اختصاص دهد. (در نتیجه ، مشتری دسترسی کامل به اطلاعات کاربر ندارد و فقط دسترسی مورد توافق را دریافت می کند. به عنوان مثال ، در سناریوی ما ، مشتری فقط برای خواندن پست های کاربر نیاز به دسترسی دارد ، بنابراین وقتی می خواهد درخواست کند ، دیگر نیازی به مجوز. برخی دیگر مانند راه‌اندازی اینستاگرام را دوست دارند.)

۳- پس از تأیید کاربر ، سرور مجوز اطلاعات کاربر ، همان نام کاربری و رمز عبور را بررسی می کند و در صورت صحت اطلاعات ، آن را Access_token ایجاد می کند و آن را برای مشتری تغییر مسیر می دهد.

4- مشتری باید این دسترسی را در جایی ذخیره کند.

5- از این پس ، هر زمان که مشتری بخواهد به اینستاگرام (مثلاً درخواست ده پست آخر) بپردازد ، باید به همراه درخواست خود ، Access_token را ارسال کند.

6. اینستاگرام میزان اعتبار Access_token دریافت شده با کمک سرور تأیید اعتبار را بررسی می کند و در صورت بروز مشکلی ، درخواست مشتری را پردازش می کند و جواب را برای مشتری ارسال می کند.

فرآیند شرح داده شده یکی از ساده ترین جریان ها در OAuth2 است. در OAuth2 در مجموع چهار جریان یا اصطلاحا انواع کمک هزینه وجود دارد که در مقاله بعدی با جزئیات بیشتری توضیح داده می شود.

برای نشانه ها ، بدانید که در OAuth2 ، تنها نشانه ارائه شده access_token نیست ، و نشانه دیگری به نام Refr_took وجود دارد که در مقاله بعدی مورد بحث قرار خواهد گرفت.

OAuth2 در عمل 1. شرکت انتشارات منینگ