تفاوت میان نسخه‌های «SSO OAuth2»

از متن باز سامان - مدیریت دانش
[نسخهٔ بررسی‌نشده][نسخهٔ بررسی‌نشده]
خط ۸: خط ۸:
  
 
=== OAuth2 Roles ===
 
=== OAuth2 Roles ===
چهار roles تعریف شده در OAuth:
+
چهار role تعریف شده در OAuth:
  
Resource Owner: کاربری است که به یک application مجوز دسترسی به حساب کاربری خودش را می‌دهد. و محدودیت این دسترسی بستگی به مجوزی دارد که کاربر می‌دهد.
+
* Resource Owner: کاربری است که به یک application مجوز دسترسی به حساب کاربری خودش را می‌دهد. و محدودیت این دسترسی بستگی به مجوزی دارد که کاربر می‌دهد.
 +
* Client: همان application است که می‌خواهد به حساب کاربری، کاربر ذکر شده دسترسی داشته باشد. که  ابتدا مجوز آن باید توسط کاربر صادر شود و همچنین توسط API تایید شود.
 +
* Resource Server: میزبان حساب های کاربری محافظت شده.
 +
* Authorization Server: هویت کاربر را تایید می‌کند و سپس token های دسترسی به application را صادر می‌کند.
  
Client: همان application است که می‌خواهد به حساب کاربری، کاربر ذکر شده دسترسی داشته باشد. که  ابتدا مجوز آن باید توسط کاربر صادر شود و همچنین توسط API تایید شود.
+
از دید توسعه دهندگان application، یک سرویس API به تنهایی می‌تواند از پس کارهای Resource Server و Authorization Server بربیاید. در ادامه به هر دوی این roll های ترکیب شده، به عنوان role های API و Server اشاره خواهیم کرد.
 
 
Resource Server: میزبان حساب های کاربری محافظت شده.
 
 
 
Authorization Server: هویت کاربر را تایید می‌کند و سپس token های دسترسی به application را صادر می‌کند.
 
  
 +
=== Abstract Protocol Flow ===
 +
با توجه به این که دید کلی نسبت به role های OAuth2 ایجاد شده است بیاید چگونگی تعامل آن ها با یکدیگر را در شکل زیر بررسی کنیم. 
 +
[[پرونده:Abstract flow.png|حاشیه|وسط|بندانگشتی|452x452پیکسل]]'''توضیحات دقیق تر طبق شماره گزاری شکل بالا:'''
  
از دید توسعه دهندگان application یک API سرویس، به تنهایی می‌تواند از پس کارهای Resource Server و Authorization Server بربیاید. به هر دوی این roll های ترکیب شده، با نقش های API و Server اشاره خواهیم کرد.
+
# درخواست مجوز Application از کاربر برای دسترسی به منابع
 +
# اگر درخواست مورد تایید User باشد، مجوز مورد نیاز را به Aplication ارسال می‌کند.
 +
#
  
=== Abstract Protocol Flow ===
+
<blockquote></blockquote>
با توجه به این که دید کلی نسبت به role های OAuth2 ایجاد شد.
 
[[پرونده:Abstract flow.png|حاشیه|وسط|بندانگشتی|452x452پیکسل]]
 

نسخهٔ ‏۱ اوت ۲۰۲۲، ساعت ۰۹:۵۵

پروتکل OAuth2

در این مقاله سعی داریم در مورد پروتکل OAuth2 و نحوه کارکرد آن توضیح دهیم.

معرفی

پروتکل OAuth2 یک فریم‌ورک جهت احراز هویت و کنترل دسترسی برای برنامه‌های دیگر هست که بصورت تحت وب سرویس خودش را ارائه می‌کند. سایر برنامه‌ها ورود کاربر و کنترل ورود آن را به این سرویس تفویض می‌کنند. این سرویس از یک جریان کلی (flow) جهت کنترل دسترسی استفاده می‌کند که می‌تواند برای برنامه‌های دسکتاپ، وب و موبایل استفاده شود.

این مقاله برای توسعه‌دهندگان نوشته شده است و یک توضیح کلی در مورد roles, authorization grant types, flow در اختیار شما قرار می‌دهد.

OAuth2 Roles

چهار role تعریف شده در OAuth:

  • Resource Owner: کاربری است که به یک application مجوز دسترسی به حساب کاربری خودش را می‌دهد. و محدودیت این دسترسی بستگی به مجوزی دارد که کاربر می‌دهد.
  • Client: همان application است که می‌خواهد به حساب کاربری، کاربر ذکر شده دسترسی داشته باشد. که ابتدا مجوز آن باید توسط کاربر صادر شود و همچنین توسط API تایید شود.
  • Resource Server: میزبان حساب های کاربری محافظت شده.
  • Authorization Server: هویت کاربر را تایید می‌کند و سپس token های دسترسی به application را صادر می‌کند.

از دید توسعه دهندگان application، یک سرویس API به تنهایی می‌تواند از پس کارهای Resource Server و Authorization Server بربیاید. در ادامه به هر دوی این roll های ترکیب شده، به عنوان role های API و Server اشاره خواهیم کرد.

Abstract Protocol Flow

با توجه به این که دید کلی نسبت به role های OAuth2 ایجاد شده است بیاید چگونگی تعامل آن ها با یکدیگر را در شکل زیر بررسی کنیم.

Abstract flow.png

توضیحات دقیق تر طبق شماره گزاری شکل بالا:

  1. درخواست مجوز Application از کاربر برای دسترسی به منابع
  2. اگر درخواست مورد تایید User باشد، مجوز مورد نیاز را به Aplication ارسال می‌کند.