بازدید کننده 3929 یکشنبه 23 تیر 1398 گروه: عمومی چاپ

در مدل‌های قدیمی احراز هویت کلاینت-سرور، درخواست‌های کاربران یا کلاینت‌ها به منابع محافظت‌شده توسط مجوزهای کلاینت که از طرف سرور تعیین شده بود، مدیریت و احراز هویت می‌شد. حال برای دسترسی نرم‌افزارها یا پکیج‌های دیگر در وب اپلیکیشن شما، به منابع محدود شده، مجوزهای کاربر یا کلاینت با این نرم افزارها و پکیج ها به اشتراک گذاشته می‌شود. این روش مشکلاتی را به وجود می‌آورد که عبارتند از:

  • همواره نرم افزارها و پکیج‌ها باید مجوزهای کاربر یا کلاینت را درون خود ذخیره می‌کردند تا در ادامه روند برنامه بتوانند از آن استفاده کنند.
  • سرورها باید احراز هویت پسورد را علارغم ضعیف بودن پسوردها، مورد پشتیبانی قرار می‌دادند.
  • کاربران یا کلاینت‌ها نمی‌توانند دسترسی را برای یک نرم افزار یا پکیج خاص محدود کنند و برای اینکار باید پسوردها را برای هر نرم افزار یا پکیج تغییر دهند.

حال فریم ورک OAuth این موضوع را بدین صورت حل کرد که یک لایه‌ی احراز هویت (Authorization Layer) ایجاد کرده و نقش کلاینت (کلاینت می‌تواند کاربر یا مرورگر یا یک نرم‌افزار باشد) را از مجوز دسترسی آن جدا کند. در نتیجه به جای استفاده از مجوزهای دسترسی برای منابع محافظت شده می‌توان از اکسس توکن (access_token) استفاده کرد. که این access token به صورت یک رشته حاوی حروف و اعداد ایجاد می‌شود و دارای زمان انقضاء، اسکوپ (یا محدوده) و سایر ویژگی‌ها است. access token ها به هر یک از نرم‌افزارها یا پکیج‌ها یا کاربران توسط یک سرور احراز هویت اختصاص داده می‌شوند. حال کاربر یا کلاینت از این access token برای دسترسی به منابع و بخش‌های مختلف استفاده می‌کند. برای مثال یک کاربر می‌تواند به تصاویر ذخیره شده اش در یک منبع دسترسی داشته باشد بدون آنکه اطلاعات یوزرنیم و پسوردش را وارد کند.

نقش ها (Roles)

به صورت کلی OAuth چهار نقش را معرفی می‌کند:

resource owner: یک موجودیت (فرد یا نرم‌افزار) که به منابع محافظت شده دسترسی دارد. در صورتیکه این موجودیت یک فرد باشد به آن end-user یا کاربر نهایی می‌گویند. (به عنوان مثال یک کاربر که دارند اکانت فیس بوک است و اطلاعات درون فیس بوک او به عنوان منابع محافظت شده هستند. در واقع این حساب کاربری به عنوان یک منبع خودی تلقی می‌شود)

resource server: سروری که منابع محافظت شده را درون خود نگه‌داری و نسبت به درخواست‌ها با استفاده از access token پاسخی صادر می‌کند. (مانند وب سایت فیس بوک که اطلاعات کاربران را درون خود نگه‌داری می‌کند)

client: یک نرم‌افزار یا کاربر که یک درخواست برای دسترسی به منابع محافظت شده را برای یک موجودیت ارسال می‌کند. (مثلا نرم افزاری که می‌خواهد درخواستی را برای سرور فیس بوک یا حساب کاربری شخصی در فیس بوک ارسال کند)

authorization server: یک سرور که access token ها را برای کاربری که به صورت موفقیت آمیز احراز هویت شده است را صادر می‌کند.

اگر بخواهیم برای این چهار نقش یک دیاگرام مناسب ترسیم کنیم، خواهیم داشت:

OAuth 2.0

همانطور که در دیاگرام فوق ملاحظه می‌کنید ابتدا کاربر یا کلاینت یک درخواست به نرم افزار دیگر (مانند فیس بوک) ارسال می‌کند و این درخواست توسط کاربری که در این نرم افزار اکانت یا حساب کاربری دارد تایید می‌شود. کلاینت یا کاربر با استفاده از این درخواست، تقاضای دسترسی به access token را به سرور احراز هویت ارسال می‌کند و پس از تایید کردن و اعتبارسنجی این درخواست، یک access token برای کاربر یا کلاینت تعریف می‌شود و در نهایت امر این access token به سرور ارسال خواهد شد و فایل‌های محافظت شده در سرور داخلی در اختیار کاربر قرار می‌گیرد.

اعطای مجوز (Authorization Grant)

یک مجوز اعطا شده عبارت است از مجوزی که توسط کاربر یا یک شخص برای دسترسی به فایل‌های شخصی‌اش و دستیابی به یک اکسس توکن (access_token) اعطا می‌شود. (به عنوان مثال یک کاربر فیس بوک اجازه می‌دهد که نرم افزار گوگل به حساب کاربر او متصل شود). این اعطای مجوز دارای ۴ نوع است که شامل موارد زیر می‌باشد:

Authorization Code: این نوع توسط سرور احزار هویت به عنوان یک میانجی بین کاربر (کلاینت) و نرم افزاری که کاربری در آن عضو است تعیین می‌شود. در واقع در این مدل به جای ارسال درخواست احراز هویت از resource owner، کاربر یا کلاینت به صورت مستقیم، resource owner را به سرور احراز هویت متصل می‌کند.

Implicit: این نوع در واقع ساده‌شده‌ی روش Authorization code است. در این مدل به جای صادر کردن مجوز برای یک کاربر یا کلاینت، کلاینت به صورت مستقیم access token را بدست می‌آورد.

Resource Owner Password Credentials: در این نوع اطلاعات کاربری مانند username و password به صورت مستقیم برای دستیابی به access token در اختیار سرور قرار می‌گیرد. از این روش معمولا زمانی استفاده می‌کنند که سیستم کاربری و احراز هویت و درخواست ها درون یک سرور انجام گیرد.

Client Credentials: از این نوع زمانی استفاده می‌شود که بخواهیم احراز هویت را برای یک اسکوپ یا منبع مشخصی تعیین کنیم.

Access Token

Access Token ها مجوزهایی هستند که برای دسترسی به منابع محافظت شده مورد استفاده قرار می‌گیرند. یک Access Token در واقع شامل مجموعه‌ای از رشته‌ها و اعداد است که توسط کلاینت مورد استفاده قرار می‌گیرند و به عنوان پاسپورد یا برگه‌ی ورود کاربر یا کلاینت محسوب می‌شود. هر Access Token دارای یک طول عمر، مقدار و سایر ویژگی‌های مشخص است.

Refresh Token

Refresh Token ها مجوزهایی هستند که برای تعیین Access Token ها مورد استفاده قرار می‌گیرند. Refresh Token ها در واقع توسط سرور احراز هویت برای کاربران (کلاینت‌ها) صادر می‌شوند و معمولا برای ایجاد Access Token هایی که طول عمر آنها به اتمام رسیده است مورد استفاده قرار می‌گیرد.

ثبت کلاینت (Client Registration)

قبل از مقداردهی اولیه‌ی پروتکل OAuth، کلاینت توسط سرور احراز هویت ثبت می‌شود. بدین معنی که ثبت این کلاینت درون یک اسکوپ یا محیط محدود صورت می‌پذیرد. برای ثبت کلاینت، نوع کلاینت و شناسه‌ی کلاینت حائز اهمیت است. بنابراین به توضیح این دو مورد خواهیم پرداخت:

نوع کلاینت

فریم ورک OAuth دو نوع کلاینت در اختیار دارد که بر اساس توانایی هر یک می‌توان از آنها استفاده کرد. این توانایی ها برای تعیین امنیت احراز هویت در سرور احراز هویت اعمال می‌شوند:

confidential: این نوع کلاینت به صورت محرمانه می‌باشد و مجوزها را به صورت محرمانه نگه می‌دارد. به عبارت دیگر کلاینت پیاده سازی شده روی یک سرور امن با محدود کردن دسترسی به مجوزهای آن کلاینت امکان پذیر خواهد بود. یعنی مجوزهای یک کلاینت را با دسترسی محدود در اختیار سرور قرار می‌دهیم.

public: این نوع کلاینت به صورت عمومی در اختیار سرور و سایر اپلیکیشن هاست.

شناسه کلاینت (Client Identifier)

سرور احراز هویت یک کلاینت ثبت شده را به همراه یک شناسه که معمولا یکتا است معرفی می‌کند. این شناسه اغلب اوقات شامل مجموعه‌‍ای از رشته ها است.

احراز هویت کلاینت (Client Authentication)

در صورتیکه نوع کلاینت به صورت confidential یا محرمانه تعریف شود، کلاینت و سرور احراز هویت یک متد احراز هویت مناسب را برای برقراری امنیت در سرور ایجاد می‌کنند. در حالت کلی یک متد به عنوان معیار واحد در نظر گرفته می‌شود که تحت عنوان Client Password معرفی خواهد شد.

Client Password: کلاینت‌ها همگی به صورت یک پسورد مشخص بر روی سرور احراز هویت ذخیره می‌شوند. مفهوم Password بدین صورت است که شناسه‌ی کلاینت به صورت یک کد رمزگذاری شده شامل مجموعه ای از رشته ها درون پایگاه داده ذخیره می‌شود.


به اشتراک بگذارید