تفاوت میان نسخههای «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 ایجاد شد.