آشنایی با OAuth 2.0 (انواع Authorization Grant – نوع اول)

آشنایی با OAuth 2.0 (انواع Authorization Grant – نوع اول)

آشنایی با OAuth 2.0 (انواع Authorization Grant – نوع اول)

همانطور که می دانید OAuth 2 یک فریم ورک یا پروتکل صدور مجور (authorization) است که به برنامه ها اجازه می دهد که بدون داشتن رمز عبور و اطلاعات حساس، از طریق پروتکل HTTP به منابع مشخصی مثل اطلاعات کاربران دسترسی داشته باشند. ما با روند کلی کار OAuth در قسمت قبل آشنا شدیم و در مورد مفاهیم پایه مانند Client ID و Client Secret صحبت کردیم. ما می دانیم که با استفاده از Client ID و Client Secret می توانیم به منابع مشخصی دسترسی پیدا کنیم اما نحوه ی این دسترسی و سطح دسترسی ها بستگی به نوع authorization grant دارد. قبل از مطالعه ی این مقاله باید با API ها و اصطلاحات آن ها آشنایی داشته باشید. برای شروع می توانید مقاله ی «آشنایی با REST API» را مطالعه کنید.

انواع authorization grant

همانطور که در 6 مرحله ی اصلی کار با OAuth توضیح دادم، چهار مرحله ی اول صرف دریافت authorization grant  و توکن دسترسی می شوند تا برنامه بتواند از طریق OAuth با سرور API تعامل داشته باشد. در OAuth انواع مختلفی از authorization grant ها وجود دارد یا به زبان ساده تر انواع مختلفی از «دسترسی» وجود دارد که هر کدام برای هدف خاصی استفاده می شود. نوع authorization grant دریافتیِ برنامه ی شما، بستگی به متد استفاده شده توسط برنامه برای درخواست authorization grant دارد. ما در OAuth چهار نوع مختلف از authorization grant ها را داریم:

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

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

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

متوجه هستم که این چهار حالت برای شما گنگ می باشند بنابراین بیایید هر کدام را جداگانه بررسی کنیم.

نوع اول: Authorization Code

این grant type (نوع دسترسی) رایج ترین نوع grant type می باشد چرا که با برنامه های سمت سرور کار کرده و در آن Client Secret همیشه مخفی می ماند. در چنین نوعی از دسترسی برنامه ی شما باید توانایی کار کردن با user agent (مثلا مرورگر کاربر) را داشته باشد و کدهای دسترسی را که به user agent ارسال می شود، دریافت کند. جریان کاری این نوع از دسترسی در تصویر زیر آمده است:

جریان کاری برای نوع اول: Authorization Code
جریان کاری برای نوع اول: Authorization Code

مراحل نمایش داده شده در تصویر بالا به شرح زیر است:

قدم اول: لینک Authorization Code

در قدم اول ما لینکی به کاربر می دهیم که ساختار زیر را دارد:

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

من ساختار این لینک را برایتان می شکنم:

  • قسمت https://cloud.digitalocean.com/v1/oauth/authorize: همان end-point سرور API است. جایی که برنامه ی ما با سرور اتصال پیدا می کند (اگر با این مفهوم آشنا نیستید مقاله ی «آشنایی با REST API» را مطالعه کنید).
  • قسمت client_id=client_id: همان client ID شما است و از طریق آن برنامه ی شما شناسایی می شود بنابراین باید به جای client_id دوم، مقدار واقعی client_id خود را قرار دهید.
  • قسمت redirect_uri=CALLBACK_URL: زمانی که کد دسترسی تایید شود، کاربر به این صفحه از وب سایت یا برنامه ی شما منتقل خواهد شد. اگر برنامه ی شما یک ربات است، پاسخ دریافتی از سرور به این قسمت ارسال می شود.
  • قسمت response_type=code: این قسمت مشخص می کند که نوع authorization grant شما چیست. ما در اینجا code را نوشته ایم، یعنی از نوع دسترسی اول که code است.
  • قسمت scope=read: سطح دسترسی (نه نوع دسترسی) را مشخص می کند. read یعنی توانایی خواندن اطلاعات اما اگر write را هم اضافه می کردیم، توانایی نوشتن و ویرایش اطلاعات را به برنامه می دادیم.

این ساختار خاص مربوط به نوع اول از دسترسی های OAuth است و در قدم اول اتفاق می افتد. شما می توانید این لینک را به صورت یک دکمه ی «ثبت نام با گوگل» یا sign up with google در نظر بگیرید که امروزه در بسیاری از سایت ها وجود دارد.

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

زمانی که کاربر روی لینک کلیک کند، باید ابتدا وارد حساب خود در سرویس شوند. مثلا در همان دکمه ی «ثبت نام با گوگل» کاربر باید وارد حساب گوگل خود شود مگر اینکه از قبل sing in بوده باشند. سپس یک صفحه برای کاربر نمایش داده می شود و از او می خواهد درخواست دسترسی یا تایید را رد کند:

تایید را رد دسترسی توسط کاربر در Google
تایید را رد دسترسی توسط کاربر در Google
تایید را رد دسترسی توسط کاربر در DigitalOcean
تایید را رد دسترسی توسط کاربر در DigitalOcean

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

قدم سوم: دریافت Authorization Code توسط برنامه

در مثال بالا اگر کاربر روی Authorize Application یا Allow کلیک کند، به صفحه ی مورد نظر در برنامه ی ما redirect می شود. اگر یادتان باشد آدرس این صفحه را هنگام ثبت برنامه مشخص کردیم و در مورد آن توضیح دادم (به قسمت قبل مراجعه کنید). مثلا اگر برنامه ی خود را dropletbook.com فرض کنیم، آدرس redirect کاربر چیزی شبیه به آدرس زیر می شود:

https://dropletbook.com/callback?code=AUTHORIZATION_CODE

قدم چهارم: درخواست Access Token توسط برنامه

در این مرحله برنامه ی ما درخواست توکن دسترسی (access token) را به API ارسال می کند. این درخواست معمولا شامل authorization code (در مرحله ی قبل دریافت کردیم) و جزئیات احراز هویت (مثل client id و Client secret) می شود که به end-point آن API ارسال می شوند. به طور مثال درخواست زیر که از نوع POST است به سرور DigitalOcean ارسال شده است:

https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

قدم پنجم: دریافت Access Token توسط برنامه

اگر درخواست ارسالی معتبر باشد، API پاسخ خود را به همراه access token به برنامه ی ما ارسال می کند. در برخی موارد یک refresh token نیز به همراه آن ارسال می شود. تمام پاسخ سرور چیزی شبیه به شیء JSON زیر است:

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"mark@thefunkybunch.com"}}

حالا درخواست تکمیل شده و کار ما تمام شده است! همانطور که می بینید برنامه ی ما به اطلاعات کاربر دسترسی دارد (البته در سطح read) تا زمانی که token منقضی شود (قسمت expiers_in در پاسخ بالا). زمانی که توکن ما منقضی می شود می توانیم با استفاده از refresh_token یک توکن جدید درخواست کنیم.

امیدوارم توضیحات شفاف بوده باشد. در قسمت بعد سه نوع grant type باقی مانده را نیز بررسی خواهیم کرد.

نویسنده شوید

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

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

قلی زاده
12 دی 1398
مطلب مفیدی بود، سپاسگذارم.

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