کلمه ی OAuth مخفف عبارت Open Authorization، یک پروتکل استاندارد است که بر اساس آن، اطلاعات هر کاربر بدون دادن رمز عبور، به صورت محدود در اختیار برنامه های کاربردی دیگر قرار می گیرد. پروتکل OAuth، به برنامه های کاربردی این امکان را می دهد تا بدون آن که کاربران را ملزم به افشای اطلاعات محرمانه ی خود (مانند پسورد) کند، از طریق API به منابع حفاظت شده از یک سرویس وب دسترسی پیدا کنند. در حقیقت، وقتی OAuth روی یک برنامه کاربردی (برای مثال روی سرویس Gmail) فعال باشد، یک API فراهم می‌کند که برنامه های کاربردی دیگر می توانند از طریق آن API، به داده های شما دسترسی محدودی داشته باشند. این مکانیزم توسط شرکت هایی مانندAmazon ، Google ، Facebook ، Microsoft و Twitter استفاده می شود تا به کاربران اجازه دهد اطلاعات مربوط به حساب های خود را با برنامه های شخص ثالث (third party) به اشتراک بگذارند و در آن ها استفاده کنند .
برای مثال شما یک حساب کاربری روی Gmail دارید و می خواهید در Linkedin هم یک اکانت ایجاد کرده و تمامی اطلاعات تماس خود را در آن‌جا نیز داشته باشید. یک راه این است که شما به طور معمول ثبت نام کرده و تمامی دوستان و کسانی که با آن ها در تماس هستید را مجدد به Linkedin اضافه کنید و یک راه دیگر استفاده از OAuth است. به این صورت که با یک مجوز، Linkedin تمامی دوستان شما را از Gmail دریافت کند.
OAuth 2.0
پروتکل OAuth دارای دو نسخه اصلی OAuth 1.0 و OAuth 2.0 می‌باشد که هر کدام نیاز‌های مختلفی را برآورده می کند. صحبت در مورد این دو نسخه، تاریخچه و مقایسه ی آن ها را در بخش انتهایی این دوره انجام خواهیم داد زیرا هدف اصلی ما در این دوره ی آموزشی، بررسی پروتکل OAuth 2.0 است و در ادامه این دوره به آن خواهیم پرداخت. هر جا که نسخه ذکر نشده است، منظور همان OAuth 2.0 است.
عملکرد OAuth 2.0 به زبان ساده
در این بخش می خواهیم یک دید کلی و ساده از نحوه عملکرد و مراحل کار پروتکل OAuth 2.0 را بیان کنیم. شکل زیر یک نمای ساده از ساختار این پروتکل را نشان می‌دهد. این تصویر نشان دهنده 3 موجودیت می‌باشد:
- کاربر (User)
- برنامه ی اصلی که کاربر در آن ثبت نام کرده (Authorization Server) مانند google
- برنامه ی فرعی که کاربر در آن حساب کاربری ندارد و دسترسی به اطلاعات کاربر را نیاز دارد (Client).
اگر دقت کنیم مشخص است که همه ی اجزا یا موجودیت ها با هم ارتباط دارند، نه این که یکی بین دیگری قرار داشته باشد.
در توضیح شکل بالا خواهیم داشت:
- ابتدا برنامه ی کاربردی درخواست استفاده از اطلاعات کاربر را به برنامه ای که کاربر در آن اکانت دارد، ارسال می کند.
- سپس برنامه ای که کاربر در آن اکانت دارد، درخواست را دریافت کرده و به کاربر اطلاع می دهد و موافقت آن را می خواهد.
- اگر کاربر با درخواست برنامه موافقت کند، مجوز استفاده از اطلاعات را به آن می دهد.
- برنامه ی کاربردی بعد از دریافت مجوز از کاربر، یک توکن از سرور تشخیص هویت که کاربر در آن اکانت دارد، دریافت می کند و در این مرحله تشخیص هویت کاربر کامل می شود.
- در انتها برنامه ی کاربردی با استفاده از این توکن، از سرور منابع (مکانی که اطلاعات کاربر در آن جا قرار دارد)، تقاضای اطلاعات می کند.
اجزای پروتکل OAuth 2.0
در OAuth 2.0 چهار نقش تعریف شده است:
- Resource owner
- Resource server
- Authorization server
- Client
در ادامه علاوه بر معرفی این 4 نقش، می خواهیم کمی وارد جزئیات شده و اجزای دیگری که ممکن است در روند کار از آن ها نام ببریم را برایتان شرح دهیم.
Resource Owner
کاربری است که اطلاعاتی در اختیار دارد و برنامه های کاربردی برای دسترسی به آن اطلاعات نیاز به مجوز از سمت آن کاربر دارند.
Resource
در واقع همان اطلاعاتی می‌باشد که قرار است با اجازه ی کاربر، در اختیار برنامه ی کاربردی قرار گیرد. Resource می تواند شامل داده ها مانند (نام، تصاویر، اطلاعات تماس ها، اسناد) و خدمات (مانند ارسال یک مطلب در وبلاگ، انتقال وجه) یا هر منبع دیگری باشند که دارای محدودیت دسترسی است.
Resource Server
سرور منبع یک اصطلاح در OAuth 2.0 برای سرور API است. سروری که میزبانی منابع محافظت شده را بر عهده دارد و قادر به پذیرش و پاسخگویی به درخواست منابع محافظت شده، با استفاده از Access Tokenها است.
سرور منبع پس از به دست آوردن Access Token، درخواست های معتبر را مدیریت می کند. در مقیاس بزرگ ممکن است بیش از یک سرور منبع وجود داشته باشد. برای مثال Google دارای ده ها سرور منبع مانند پلتفرمGoogle Cloud ، Google Maps ، Google Drive ، Youtube ، Google+ و بسیاری دیگر است که هر کدام از این سرورهای منبع کاملا مجزا هستند، اما همه ی آن ها یک مجموعه سرور مجوز یکسان دارند.
Authorization Serve
سرور یا همان برنامه ای است که بعد از تایید Resource Owner یا همان کاربر و اخذ مجوز از او، Access Token را برای کلاینت صادر می کند. این سرور وظیفه ی تشخیص هویت برنامه های کاربردی و صدور شناسه یا Token برای آن ها، جهت استفاده از اطلاعات کاربر را بر عهده دارد. نا گفته نماند که گاهی ممکن است Resource Server و Authorization Server یکی باشند.
Authorization Grant
این عبارت به معنی اعطا کردن مجوز بوده و در اصل همان مجوزی است که Authorization Server صادر می کند.
Client
برنامه ی کاربردی ای است که درخواست دسترسی و استفاده از اطلاعات کاربر را دارد. در حقیقت کلاینت، برنامه ای است که می خواهد از طرف کاربر عمل کرده یا این که به اطلاعات کاربر دسترسی پیدا کند. کلاینت قبل از دسترسی به حساب کاربر، باید مجوز کسب کند که از 2 روش این کار انجام می‌شود:
- با هدایت کاربر به Authorization Server، مجوز را دریافت می کند.
- با ارتباط مستقیم با Authorization Server و بدون تعامل با کاربر، مجوز را دریافت می کند.
در OAuth دو نوع Client بر اساس شرایط مختلف و قابلیت ها تعریف شده است. این قابلیت ها برای تعیین امنیت احراز هویت در Authorization Server، است.
- Confidential Client: کلاینت هایی که قادر به حفظ محرمانه بودن خود هستند (برای مثال کلاینت پیاده سازی شده روی یک سرور امن با دسترسی محدود) یا قادر به احراز هویت کلاینت به صورت امن با استفاده از روش های دیگر هستند.
- Public Client: کلاینت هایی که نتوانند محرمانه بودن خود را حفظ کنند (به عنوان مثال، کلاینت هایی که در دستگاه مورد استفاده توسط صاحب منبع نصب شده یا برنامه هایی که مبتنی بر مرورگر وب اجرا می‌شوند) و قادر به احراز هویت کلاینت به صورت ایمن نیستند.
اگر بخواهیم نحوه ی ارتباط اجزای معرفی شده را به زبان ساده بیان کنیم، شکل زیر این کار را برای ما انجام خواهد داد:
بر اساس اجزایی که معرفی شد، ساختار پروتکل OAuth 2.0 و دیاگرام روند اجرای آن به صورت زیر خواهد بود:
جمع بندی
در این بخش از دوره ی آموزشی OAuth 2.0، با نحوه ی عملکرد این استاندارد به زبان ساده آشنا شدیم. در ادامه ی این دوره با ما همراه باشید تا کمی عمیق تر به این موضوع بپردازیم و با انواع روش های احراز هویت OAuth آشنا شویم.
