Client Credentials


در فصل اول مفاهیم پایه و مرتبط با OAuth را بیان کردیم و سپس به معرفی پروتکل OAuth 2.0 پرداختیم و ساختار آن را تشریح نمودیم. در این فصل می‌خواهیم انواع Grant در OAuth 2.0 را معرفی کرده و عملکرد هر کدام از آن‌ها را توضیح دهیم. 

OAuth Grant Types  


پروتکل OAuth چندین Grant Type با کاربرد‌های مختلف و همچنین چارچوبی برای ایجاد Grant Type جدید مشخص می‌کند. در  OAuth 2.0اصطلاح “Grant Type” به روشی که یک برنامه برای گرفتن Access Token از آن استفاده می‌کند، گفته می‌شود. متداول ترین انواع OAuth Grant عبارت‌اند از:

·         Client Credentials

·         Authorization Code

·         PKCE

·         Device Code

·         Refresh Token

·         Legacy: Implicit Flow

·         Legacy: Password Grant

 

در ادامه به معرفی هر کدام از این موارد خواهیم پرداخت.

 

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"
}

در بخش بعد هم با ما همراه باشید تا نوع بعدی مجوز را معرفی کنیم. 

لیست نظرات
کاربر میهمان
دیدگاه شما چیست؟
کاربر میهمان