آشنایی با OAuth 2.0 (جریان کاری OAuth)

آشنایی با OAuth 2.0 (جریان کاری OAuth)

آشنایی با OAuth 2.0 (جریان کاری OAuth)

OAuth 2 یک فریم ورک یا پروتکل صدور مجور (authorization) است که به برنامه ها اجازه می دهد که بدون داشتن رمز عبور و اطلاعات حساس، از طریق پروتکل HTTP به منابع مشخصی مثل اطلاعات کاربران دسترسی داشته باشند. چنین مواردی را حتما در API وب سایت هایی مانند GitHub دیده اید. در واقع شما با استفاده از OAuth 2.0 می توانید اطلاعات یک کاربر در یک سایت دیگر را بخوانید (البته به صورت محدود) بدون اینکه به رمز عبور آن کاربر دسترسی داشته باشید.

OAuth 2.0 چهار «نقش» یا role تعریف می کند:

  • Resource Owner یا صاحب منابع (کاربر)
  • Client یا برنامه ی ما
  • Resource Server یا سرور حاوی منابع
  • Authorization Server یا سرور احراز هویت

ما برای درک OAuth 2.0 باید با این چهار نقش آشنا باشیم.

نقش اول: Resource Owner – این نقش همان user یا کاربر است و نقشی است که دارای منابع (فایل ها یا اطلاعات) مشخص است. user در تعریف اصلی همان فردی است که به یک application (برنامه) اجازه ی دسترسی به اطلاعاتش را می دهد (از طریق یک token). این دسترسی بنابر سطح دسترسی مشخص شده توسط کاربر یا scope دسترسی محدود خواهد بود. مثلا آیا برنامه اجازه ی انجام دستورات read و Write را دارد؟

نقش دوم: Client – کلاینت همان برنامه یا application ای است که می خواهد با استفاده از این پروتکل به سرور متصل شده و به اطلاعات کاربر برسد. به طور مثال در دنیای وب، کلاینت معمولا همان مرورگر کاربر است.

نقش سوم و چهارم: Resource / Authorization Server – از آنجایی که در فضای وب معمولا هر دو عملیات احراز هویت و نگهداری از منابع توسط یک سرور یا یک مجموعه سرور انجام می شود این دو نقش را ترکیب کرده ایم و در کل مقاله با عنوان API به آن اشاره می کنیم چرا که این نقش در واقع همان API می باشد.

حالا که با نقش های OAuth آشنا شدید باید نحوه ی تعامل آن ها با یکدیگر را نیز درک کنید:

جریان کاری OAuth 2.0 به صورت عمومی
جریان کاری OAuth 2.0 به صورت عمومی

تصویر بالا جریان کاری OAuth 2 را برای شما ترسیم کرده است. البته این تصویر یک جریان کلی برای مفهوم OAuth است و در grant type های متخلف متفاوت خواهد بود (در قسمت بعد در مورد انواع این grant ها توضیح خواهیم داد) بنابراین از آن فقط در جهت درک نحوه ی کلی کار OAuth استفاده کنید. این مراحل به ترتیب عبارت اند از:

  1. برنامه (application) درخواست دسترسی به اطلاعات کاربر را به سرور ارسال می کند.
  2. اگر کاربر چنین درخواستی را تایید کرده باشد، authorization تایید می شود.
  3. برنامه درخواست توکن دسترسی را به API ارسال می کند که حاوی اطلاعات احراز هویت خود برنامه به علاوه ی تاییدیه ی authorization از سمت کاربر است.
  4. اگر هویت برنامه و تاییدیه ی authorization معتبر باشند، API یک توکن دسترسی را به برنامه می دهد. در این مرحله پروسه ی authorization و احراز هویت تکمیل و تمام می شود.
  5. برنامه منابع (resource) مورد نظر خود را از API درخواست کرده و توکن خود را به همراه درخواست ارسال می کند.
  6. اگر توکن دسترسی معتبر باشد API اطلاعات مورد نظر را برای برنامه ارسال می کند.

البته روند اجرای مراحل بالا بر اساس نوع دسترسی که به شما داده شده است متفاوت خواهد بود اما مفهوم کلی OAuth در همین شش مرحله خلاصه می شود. توجه داشته باشید که چهار مرحله ی اول برای دریافت مفهومی به نام authorization grant (مجوز دسترسی) انجام می شوند.

ثبت برنامه

تمامی مراحلی که تا اینجای کار گفته شد مربوط به روند کاری ارتباط با OAuth بودند اما قبل از اینکه بخواهید با OAuth کار کنید باید برنامه ی خود را در سرورهای هدف ثبت کرده باشید. مثلا اگر می خواهید از API گیت هاب استفاده کنید دو گزینه دارید:

  • استفاده از API گیت هاب بدون OAuth – در این حالت تعداد درخواست های شما محدود است (مثلا 100 درخواست در ساعت).
  • ثبت برنامه در API گیت هاب و کار از طریق OAuth – در این حالت می توانید در هر ساعت 5000 درخواست ارسال کنید.

عملیات ثبت برنامه معمولا توسط یک فرم ساده در وب سایت مورد نظر شما انجام می شود و کار خاصی ندارد. در این فرم اطلاعاتی مثل نام برنامه و آدرس وب سایت شما از شما پرسیده می شود. همچنین مقداری تحت عنوان Redirect URI  یا Callback URL نیز از شما خواسته می شود. این مقدار همان آدرسی است که کاربر به آن redirect شده یا پاسخ درخواست به API برایتان ارسال می شود. به طور مثال کسی که با دکمه ی sign up with google در وب سایت شما ثبت نام می کند پس از کلیک روی این دکمه به گوگل می رود و پس از ورود به حساب کاربری خود به صفحه ای از سایت شما برگردانده می شود که آدرس آن به شما بستگی دارد و همان Redirect URI است. به زبان ساده تر این مقدار همان قسمتی از سایت یا برنامه ی شما است که مسئول مدیریت این نوع درخواست ها می باشد.

به طور مثال برای API گیت هاب، این فرم درون حساب کاربری، قسمت dashboard و قسمت توسعه دهندگان قرار دارد. به زودی در مجموعه ی «پروژه های مدرن جاوا اسکریپت» پروژه ای ساده برای کار با API گیت هاب منتشر می شود و در آنجا به صورت عملی کار را مشاهده می کنید بنابراین به این قسمت سری بزنید.

Client ID و Client Secret چیست؟

زمانی که برنامه ی خود را در وب سایت مورد نظر ثبت کنید، سرویس مورد نظر (مثلا گیت هاب) دسته ای از اطلاعات به نام client credentials را به شما می دهد. این داده ها شامل دو قسمت مهم است:

  • Client Identifier یا همان client ID که یک رشته ی خاص برای شناسایی برنامه ی شما توسط سرور است و معمولا همه می توانند آن را مشاهده کنند.
  • Client Secret که معادل رمز عبور برای برنامه ی شما در OAuth می باشد و سرور هویت اصلی شما را توسط این رشته تعیین می کند. این مقدار باید بین سرور شما و API هدف باشد و دیگران از آن اطلاعی نداشته باشند.

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

نویسنده شوید

دیدگاه‌های شما (1 دیدگاه)

در این قسمت، به پرسش‌های تخصصی شما درباره‌ی محتوای مقاله پاسخ داده نمی‌شود. سوالات خود را اینجا بپرسید.

رامین
29 آذر 1398
این oauth خیلی مهمه کاش یه پروژه ای چیزی واسش بزاری

در این قسمت، به پرسش‌های تخصصی شما درباره‌ی محتوای مقاله پاسخ داده نمی‌شود. سوالات خود را اینجا بپرسید.

امیر زوارمی
02 دی 1398
سلام دوست عزیز سری «پروژه های مدرن جاوا اسکریپت» رو دنبال کنید. اونجا یه پروژه ی کار با github داریم که از OAuth استفاده می کنه. البته سعی می کنم در آینده هم پروژه های کامل تری رو تهیه کنم.

در این قسمت، به پرسش‌های تخصصی شما درباره‌ی محتوای مقاله پاسخ داده نمی‌شود. سوالات خود را اینجا بپرسید.