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

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

نسخهٔ ‏۱ اوت ۲۰۲۲، ساعت ۰۷:۳۱

پروتکل OAuth2

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

معرفی

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

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

OAuth2 Roles

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

Resource Owner: کاربری است که به یک application مجوز دسترسی به حساب کاربری خودش را می‌دهد. و محدودیت این دسترسی بستگی به مجوزی دارد که کاربر می‌دهد.

Client: همان application است که می‌خواهد به حساب کاربری، کاربر ذکر شده دسترسی داشته باشد. که ابتدا مجوز آن باید توسط کاربر صادر شود و همچنین توسط API تایید شود.

Resource Server: میزبان حساب های کاربری محافظت شده.

Authorization Server: هویت کاربر را تایید می‌کند و سپس token های دسترسی به application را صادر می‌کند.


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

Abstract Protocol Flow

با توجه به این که دید کلی نسبت به role های OAuth2 ایجاد شد.

Abstract flow.png