در فصل اول از دوره ی آموزشی OAuth، در مورد مفاهیم پایه و مرتبط با OAuth صحبت کردیم. سپس به معرفی پروتکل OAuth 2.0 پرداختیم و ساختار آن را تشریح نمودیم. در این فصل می‌خواهیم انواع Grant در OAuth 2.0 را معرفی کرده و عملکرد هر کدام از آن ها را توضیح دهیم. جهت آشنایی با مفاهیم پایه، به بخش مقدمه مراجعه کنید.
انواع Grant در OAuth
پروتکل OAuth، چند نوع Grant با کاربرد‌های مختلف دارد. همچنین چارچوبی برای ایجاد یک نوع جدید از Grant مشخص می‌کند. در OAuth 2.0اصطلاح“Grant Type” به روشی که یک برنامه برای گرفتن Access Token از آن استفاده می‌کند، گفته میشود. رایج ترین انواع OAuth Grant عبارت‌اند از:
- Client Credentials
- Authorization Code
- PKCE
- Device Code
- Refresh Token
- Legacy: Implicit Flow
- Legacy: Password Grant
در ادامه این فصل، به معرفی هر کدام از این موارد خواهیم پرداخت اما در این بخش، در مورد Client Credentials صحبت می کنیم.
1- Client Credentials
یکی از انواع Grant ها،Client Credentials می‌باشد و هنگامی استفاده میشود که خود برنامه ها برای دسترسی به منابع مورد نیاز خود، نه از طرف یک کاربر، Access Token را درخواست می‌کنند. در حقیقت این روند برای شرایطی است که کاربری وجود ندارد مانند زمانی که سرور نیاز داشته باشد که به یک API خاص متصل شود. بنابراین سرور قرار نیست با اجازه از سمت کسی بهAPI دسترسی داشته باشد بلکه خود سرور به صورت مستقیم از API استفاده خواهد کرد. همان طور که گفته شد، به طور معمول کلاینت هایی از این استفاده می کنند که می خواهند به منابع مربوط به خودشان دسترسی داشته باشند نه به منابع کاربر.
در این حالت Client یا همان برنامه ی کاربردی به جای این که با اجازه ی کاربر، Access Token را دریافت کند، با استفاده ازClient ID و Client Secretمختص به خود، یک Access Token از Authorization Server درخواست می‌کند. سپس با استفاده از آن token، به صورت مستقیم باResource Server وارد تعامل خواهد شد. شکل زیر این تعامل را نشان می‌دهد.
پارامتر‌هایی که در درخواست Access Token وجود دارد به شرح زیر است:
- grant_type (پارامتر ضروری): پارامتر grant_type باید روی client_credentials تنظیم شود.
- scope (پارامتر اختیاری): سرویس شما می تواند scope های مختلفی را برای client credential پشتیبانی کند. البته در عمل بسیاری از سرویس ها از این مورد پشتیبانی نمی‌کنند. در فصل های آینده در مورد scope ها صحبت خواهیم کرد.
- Client Authentication (پارامتر ضروری): بخشی از درخواست کلاینت، از Authorization Server است که به وسیله ی آن، احراز هویت کلاینت بررسی و تایید میشود. به طور معمول این بخش که شامل پارامترهای client_id و client_secret است، در بدنه ی درخواست و یا در هدر درخواست قرار می‌گیرد.
مثال زیر درخواست مجوز برای دسترسی ای است که Authorization Server از کلاینت دریافت می‌کند.
POST /token HTTP/1.1
Host: authorization-server.com
grant_type=client_credentials
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx
در صورتی که پاسخ موفقیت آمیز باشد و در واقع درخواست access token معتبر باشد،Authorization Server باید یک access token ایجاد کند و همراه با سایر property های اضافی مربوط به مجوز، به کلاینت برگرداند.
پاسخ Authorization Server دارای گزینه های زیر است:
- access_token (ضروری): رشته ی access token که توسط authorization server صادر شده است.
- token_type (ضروری): نشان دهنده ی نوع توکن بوده که به طور معمول bearer است.
- expires_in (توصیه می شود): تاریخ انقضای توکن.
- refresh_token (اختیاری): همان طور که در بخش اصطلاحات توضیح داده شد، بعد از منقضی شدن توکن، برای دریافت توکن جدید استفاده می شود.
- scope (اختیاری): نشان دهنده ی محدودیت های دسترسی است که در آینده به آن می پردازیم.
همچنین در پاسخ Authorization Server به درخواست access token، سرور باید اطلاعات اضافی را در HTTP headers داشته باشد تا مطمئن شود که کلاینت ها این درخواست را cache نمی‌کنند. مانند:
Cache-Control: no-store
و Pragma: no-cache
برای مثال، یک پاسخ موفقیت آمیز برای توکن ممکن است مانند زیر باشد:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
"scope":"create"
}
در بخش بعد، نوع دیگری از مجوز را برایتان شرح خواهیم داد پس لطفا با ما همراه باشید.
