SSO OAuth2
پروتکل 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 ایجاد شده است بیاید چگونگی تعامل آن ها با یکدیگر را در شکل زیر بررسی کنیم.
توضیحات دقیق تر طبق شماره گزاری شکل بالا:
- درخواست مجوز Application از کاربر برای دسترسی به منابع
- اگر درخواست مورد تایید User باشد، مجوز مورد نیاز را به Application ارسال میکند
- در این مرحله Application با احراز کردن هویت خود و ارائه مجوز، Access Token را از Authorization Server (API) درخواست میکند
- اگر احراز هویت Application و مجوز ارائه شده مورد تایید باشد Access Token توسط Authorization Server (API) به Application ارسال می‌شود
- Application با ارائه Access Token درخواست خود برای دسترسی به منابع را به Resource Server (API) ارسال میکند
- در صورت صحیح بودن Access Token منابع مورد نظر توسط سرویس Resource Server (API) در اختیار Application قرار می‌گیرد
جریان (flow) واقعی عملکرد این فرایند به نوع مجوز استفاده شده بستگی دارد اما این ایده کلی است. در ادامه انواع مختلف مجوز ها را مرور می‌کنیم.
Application Registration
قبل از این که Application شما از OAuth2 استفاده کند باید از طریق یک سرویس، Application خود را ثبت کنید. با پر کردن فرم ثبت نام در قسمت developer یا API سرویس وبسایت این ثبت نام انجام می‌شود. که در آن فرم اطلاعات Application شما را مطابق موارد زیر دریافت می‌کنند (اطلاعات دریافتی ممکن است جزئی تر از موارد زیر باشد).
- نام Application
- آدرس Application
- URL برگشتی (Redirect URI یا Callback URL)
URL برگشتی آدرسی است که بعد از تایید (یا عدم تایید) احراز هویت Application، کاربرتوسط سرویس به آن URL هدایت می‌شود. تعریف Application توسط مدیران سیستم انجام می‌شود.
Client ID و Client Secret
بعد از ثبت Application، سرویس client credential را در قالب client identifier و client secret صادر میکند.از این مشخصه‌ها جهت اتصال به سرویس SSO با پروتکل OAuth2.0 می‌توان استفاده کرد. این موارد می‌بایست نزد سامانه مربوطه نگهداری شود و اطلاعات عمومی محسوب نمی‌شود. برای اتصال به SSO از یک دامنه که توسط سازمان مشخص می‌شود، استفاده کنید. مثلا اینجا ما از دامنه‌ای با نام accounts.mbsco.ir استفاده کر‌ده‌ایم. بنابراین قبل از کلیه آدرسهای موجود در جدول زیر، این دامنه قرار می‌گیرد.
جدول آدرس های Endpoint سامانه
| cas/ | base url |
|---|---|
| cas/login/
|
user login url |
| cas/authorize/ | authorize prefix |
| cas/profile/ | profile prefix |
| cas/token/ | access token |
| cas/logout/ | user logout url |
Authorization Grant
در بخش Abstract Protocol Flow در چهار مرحله اول نحوه مجوز دادن (authorization grant) و access token را بررسی کردیم. نوع مجوزی که داده می‌شود به روش درخواست مجوز Application وابسته است و API باید از آن نوع مجوز پشتیبانی کند.
سه روش اصلی برای دادن مجوز توسط OAuth 2 تعریف می‌شود که هر کدام برای موارد مختلفی قابل استفاده هستنند.
- Authorization Code: برای server-side Application ها استفاده می‌شوند.
- Client Credentials: برای Application هایی که به API دسترسی دارند استفاده می‌شوند.
- Device Code: برای دستگاه هایی که مرورگر ندارند و یا محدودیت ورودی دارند استفاده می‌شوند.
هشدار
Implicit Flow و Password Grant دو نوع دیگر از انواع مجوز دادن در فریم‌ورک OAuth است. اما هر دو آن ها ناامن در نظر گرفته می‌شود و استفاده از آن ها توصیه نمی‌شود.
و حالا در بخش های بعدی به شرح جزئیات انواع مختلف دادن مجوز می‌پردازیم
Authorization Code
استفاده از Authorization Code رایج تر است چون برای Application های server-side بهینه سازی شده و source code آن ها در دسترس عموم نیست و محرمانگی Client Secret حفظ می‌شود. این یک روند redirection-based است که به معنی در تعامل بودن Application با user-agent (مرورگر کاربر) و دریافت کد مجوزAPI مشخص شده توسط user-agent است.
توضیحات نحوه عملکرد Authorization Code:
1. Authorization Code Link
ابتدا کاربر به لینکی مثل لینک زیر هدایت می‌شود:
توضیحات اجزاء نمونه لینک بالا:
https://oauth.mbsco.ir/v1/oauth/authorize: آدرس مجوز API یا ( API authorization endpoint )client_id=CLIENT_ID: این متغییر مشخص کننده client_id مخصوص Applicatin مورد نظر است و با این مقدار، Application توسط API شناسایی می‌شودredirect_uri=CALLBACK_URL: آدرسی است که user-agent بعد از دریافت کد مجوز به آن هدایت می‌شود- response_type=code: مشخص کننده این است که Application کد مجوز را درخواست میکند
- scope=profile: مشخص کننده سطح دسترسی درخواست شده توسط Application است
2. User Authorizes Application
زمانی که کاربر روی لینک کلیک میکند برای احراز هویت باید وارد service شود. سپس از کاربر توسط service خواسته می‌شود که مجاز بودن یا نبودن Application برای دسترسی به حساب کاربری خود را تعیین کند.
3. Application Receives Authorization Code
در این قسمت اگر کاربر مجاز بودن Application را تایید کند service مورد نظر user-agent را همراه با Authorization Code به redirect-url که در زمان ثبت نام Application تعیین شده، هدایت میکند.
https://CALLBACK_URL?code=AUTHORIZATION_CODE
4. Application Requests Access Token
و در این قسمت Application با ارائه Authorization Code و اطلاعات مورد نیاز دیگر برای احراز هویت مانند client secret به آدرس Api token از API مورد نظر access token را درخواست میکند.
https://oauth.mbsco.ir/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL
5. Application Receives Access Token
اگر مجوز معتبر باشد API پاسخ خود را که شامل access token ( و متغییر اختیاری refresh_token) هست را به Application ارسال میکند.
پاسخ کامل API شبیه به رشته ی زیر است.
{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"profile","uid":100101,"info":{"name":"Mark E. Mark","email":"mark@thefunkybunch.com"}}
و حالا Application ما مجوز دارد. و این token تا زمان منقضی شدن و لغو شدن معتبر است که البته ممکن است این token استفاده شده برای دسترسی به حساب کاربری از طرف Service API به یک scope دسترسی خاص محدود شده باشد.
در صورتی که refresh_token ایجاد شده باشد و access_token اصلی منقضی شده باشد این امکان وجود دارد که برای درخواست جدید از refresh_token استفاده شود.