آشنایی با OAuth 2.0 (انواع دیگر grant)

آشنایی با OAuth 2.0 (انواع دیگر grant)

آشنایی با OAuth 2.0 (انواع دیگر grant)

با سلام و خسته نباشید خدمت شما همراهان گرامی روکسو، در این قسمت قصد داریم انواع دیگر grant type را بررسی کنیم. در قسمت اول برایتان توضیح دادم که روند کلی OAuth به شکل زیر است:

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

همچنین متوجه شدیم که این روند کاری تصویری کلی از OAuth به ما می دهد اما این تصویر دقیق نیست. روند کار OAuth در هر یک از چهار grant type متفاوت است. آیا این grant type ها را به خاطر دارید؟

  • Authorization Code: شایع ترین نوع بوده و با برنامه های server-side کار می کند.
  • Implicit: برای کار با دستگاه های موبایل و برنامه های وب استفاده می شود (برنامه هایی که در دستگاه کاربر اجرا می شوند).
  • Resource Owner Password Credentials: برای برنامه های مطمئن و ایمن استفاده می شود. به طور مثال برنامه هایی که توسط خود سرویس و کمپانی ساخته شده اند و هویت آن ها 100 در 100 مشخص است.
  • Client Credentials: معمولا توسط API برنامه ها استفاده می شود.

تصویر زیر ویژگی های هر کدام را نمایش می دهد:

انواع authorization type در OAuth 2.0
انواع authorization type در OAuth 2.0

نوع اول را در قسمت قبل بررسی کرده و حالا نوبت به بررسی نوع دوم یعنی implicit grant و انواع باقی مانده ی دیگر است. این نوع از grant مخصوص نرم افزارهای موبایلی و برنامه های تحت وب است (یعنی برنامه هایی که در مرورگر اجرا می شوند). در چنین حالتی، برخلاف نوع اول یا code grant، ممکن است client secret در معرض دید عموم باشد و محفوظ ماندن آن ضمانت شده نیست. اساس این نوع Grant مانند grant نوع اول روی redirect شدن است؛ توکن دسترسی در این حالت به user-agent داده می شود تا user-agent آن را به برنامه پاس بدهد، به همین خاطر ممکن است در معرض دید خود کاربر و دیگر برنامه های سیستم باشد. همچنین باید توجه کرد که در این نوع از grant هویت برنامه احراز نمی شود و تمرکز روی URI خواهد بود و refresh token ها را نیز نخواهیم داشت.

جریان کاری این grant را در تصویر زیر برایتان آورده ام:

روند کاری implicit grant در OAuth
روند کاری implicit grant در OAuth

ابتدا از کاربر خواسته می شود که به برنامه اجازه ی دسترسی دهد، سپس سرور مربوطه توکن دسترسی را برای user-agent ارسال می کند و user-agent نیز آن را به برنامه می فرستد. بگذارید این مراحل را تک به تک بررسی کنیم.

قدم اول: لینک صدور مجوز (authorization)

در implicit gant ها معمولا به کاربر لینکی داده می شود که برای فرآیند صدور مجوز است. این لینک باعث ایجاد یک درخواست برای دریافت یک توکن از API می شود. تفاوت این لینک با لینکِ authorization code (نوع اول) در این است که به جای درخواست برای کُد، درخواست خود را برای دریافت یک توکن ارسال می کنیم. در لینک زیر توجه کنید که response type از نوع token است نه code:

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

قدم دوم: تایید دسترسی توسط کاربر

زمانی که کاربر روی این لینک کلیک می کند باید ابتدا وارد سرویس و حساب کاربری خود شود. سپس دقیقا مثل نوع اول از grant ها از کاربر خواسته می شود که دسترسی برنامه را تایید (کلماتی مثل authorize یا allow) و یا رد (deny) کند:

نمونه ای از صفحه ی تایید توسط کاربر
نمونه ای از صفحه ی تایید توسط کاربر

در تصویر بالا مشخص است که برنامه ای به نام Thedropletbook App درخواست read (خواندن اطلاعات) را برای حساب کاربری manicas@digitalocean.com داده است.

قدم سوم: دریافت توکن و URI توسط user-agent

اگر کاربر در مرحله ی قبل به برنامه اجازه ی دسترسی بدهد، سرور کاربر را به همان URI (آدرس redirect که هنگام ثبت برنامه مشخص کردیم) redirect می کند که قسمتی از آن حاوی توکن دسترسی است. مثلا آدرسی شبیه به آدرس زیر:

https://dropletbook.com/callback#token=ACCESS_TOKEN

قدم چهارم: user-agent به آدرس URI می رود

زمانی که آدرس URI به همراه توکن دسترسی (access token) برای user-agent ارسال شد، user-agent به این آدرس می رود اما توکن دسترسی را نگه می دارد.

قدم پنجم: توکن دسترسی به اسکریپت برنامه ارسال می شود

برنامه ی ما صفحه ی وب ای را برمی گرداند که حاوی اسکریپت خاصی با توانایی خارج کردن توکن دسترسی از URI می باشد.

قدم ششم: توکن دسترسی به برنامه می رسد

User-agent (مثلا مرورگر) اسکریپت ذکر شده را اجرا می کند و توکن استخراج شده را به برنامه می دهد. حالا برنامه ی ما مجوز دسترسی را گرفته است و تا زمانی که توکن منقضی نشده است می تواند از این توکن برای خواندن اطلاعات کاربر استفاده کند.

تایپ resource owner password credentials

تایپ grant بعدی ما resource owner password credentials است. در این حالت کاربر اطلاعات نام کاربری و رمز عبور خود را مستقیما در برنامه وارد می کند و برنامه از این طریق یک توکن دسترسی دریافت می کند. شما باید تا حد ممکن از این نوع Grant دوری کنید و فقط زمانی از آن استفاده شود که هیچ نوع دیگری از grant موجود نباشد. همچنین فقط در شرایطی از آن استفاده می شود که کاربر اطمینان کامل به برنامه داشته باشد و هویت سازندگان آن مشخص باشد (مثلا هنگامی که برنامه توسط خود سرویس ساخته شده باشد – مثل برنامه ی github برای ویندوز که توسط خود github ساخته شده است).

زمانی که شما رمز عبور و حساب کاربری خود را وارد برنامه کنید یک درخواست POST به شکل زیر به سرور ارسال می شود:

https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

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

تایپ client credentials

این نوع از grant برای دسترسی برنامه به منابع و اطلاعات خود برنامه است! مثلا هنگامی که برنامه بخواهد توضیحات خود یا redirect URI خود را تغییر دهد ( اگر یادتان باشد این موارد در هنگام ثبت برنامه ذخیره می شدند). در این حالت برنامه ی ما client id و client secret خود را به سرور ارسال می کند تا توکن دسترسی دریافت کند. درخواست POST در این حالت چیزی شبیه به درخواست زیر می شود:

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

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

این هم از سری مقالات کوتاه آشنایی با OAuth. برای اطلاعات بیشتر می توانید به https://tools.ietf.org/html/rfc6749 مراجعه کنید.

نویسنده شوید

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

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

بهنام قلی زاده
12 دی 1398
بسیار ممنون

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