با OAuth2 آشنا شوید. قسمت سوم

متن حاضر قسمت سوم از سری مقالات آشنایی به پروتکل OAuth2 است، اگر دو قسمت قبلی رو مطالعه نکردید، قبل از مطالعه این قسمت، سری به دو لینک زیر بزنید.

با OAuth2 آشنا شوید. قسمت اول

با OAuth2 آشنا شوید. قسمت دوم

در دو قسمت قبلی پروتکل OAuth2، کامپوننت ها و تعامل بین شون رو از دیدگاه تئوری بررسی کردیم. برای ادامه راه بهتر دونستم قبل از ارائه نکات تئوری باقی مانده سناریویی رو در دنیای واقعی پیاده سازی کنیم. این مثال عملی میتونه کمک موثری به درک بهتر پروتکل OAuth2 داشته باشه.

این نکته رو درنظر داشته باشید که از بین کامپوننت های معرفی شده در قسمت قبل، سه کامپوننت Authorization Server، Protected Resource و کلاینت باید پیاده سازی شوند. در برخی شرکت ها دو کامپوننت Protected Resource و Authorization Server تحت یک سیستم پیاده سازی می شوند که نقش هر دو کامپوننت رو بر عهده میگیره. از اونجایی که پیاده سازی این دو سیستم تسک معمول برای دولوپرها نیست و استفاده ما دولوپرها از پروتکل OAuth2 عمدتا به استفاده از Protected Server های موجود مثل گوگل و اینستاگرام محدود میشه در این مقاله صرفا پیاده سازی کلاینت رو بررسی می کنیم.

سناریو

ما در حال پیاده سازی سیستمی هستیم که کاربر بعد از Authentication میتونه به یه داشبورد دسترسی داشته باشه. در بخشی از این داشبورد قصد داریم ایمیل های اخیر کاربر لاگین شده رو نمایش بدیم.

مراحل اصلی پیاده سازی Client

• ثبت نام یک OAuth Client در Authorization Server و تنظیم کلاینت
• ارسال درخواست برای دریافت توکن های OAuth2 شامل Access Token و Refresh Token با استفاده از یکی از Flow های موجود (با توجه به اینکه Flow ها در مقاله بعدی معرفی خواهند شد،‌ در مقاله حاضر از Implicit Grant Type استفاده میکنیم.)
• استفاده از Access Token دریافت شده و ارسال درخواست به Protected Resources

مرحله ۱:‌ ثبت نام یک OAuth Client در Authorization Server

اگه دقت کرده باشید، پروسه Authorization خاصه بین Client و Authorization Server اتفاق می افته، بنابراین این دو کامپوننت قبل از هر چیزی باید همدیگه رو بشناسند. برای این کار کافیه که ما یه سری اطلاعات از سیستم خودمون (کلاینت)‌ رو در اختیار Authorization Server قرار بدیم و Authorization Server کدهایی مبنی بر معتبر بودن سیستم دراختیارمون قرار میده. این دو کد client_id و client_secret هستند.

برای سناریوی خودمون باید وارد لینک زیر بشید و با استفاده از گزینه Sign in به اکانت جیمیل خودتون وارد بشید. (برای این کار باید از فیلترشکن استفاده کنید.)

Google Developers Console

بعد از لاگین شدن با استفاده از گزینه Select a project و در مرحله بعد New project یک پروژه جدید تعریف کنید. یک نام دلخواه برای پروژه انتخاب و آن را ایجاد کنید.

از منوی Library کتابخانه Gmail API رو انتخاب و آن را فعال کنید. حواستون باشه حتما پروژه ای که ساختید رو انتخاب کرده باشید. در منوی بالا میتونید پروژه فعلی رو ببینید.

به صفحه قبل برگردید و با استفاده از منوی OAuth consent screen صفحه رضایت کاربر رو تنظیم کنید. برای این کار بعد از انتخاب گزینه External روی دکمه Create کلیک کنید و در صفحه باز شده تنظیمات رو طبق تصویر 4 تکمیل کنید.

درصورتی که قبلا این کار رو انجام دادید به مرحله بعد برید.

در مرحله بعد باید کلاینت رو بسازید. برای اینکار گزینه Credentials رو انتخاب کنید. با استفاده از گزینه Create Credentials یک OAuth client بسازید.

بعد از ثبت کلاینت دو مقدار client_id و client_secret در اختیار شما قرار می گیره. مطمئن باشید که کسی غیر از شما به client_secret دسترسی نداشته باشد.

مرحله 2: ارسال درخواست برای Access Token

این مرحله با توجه به Grant Type انتخاب شده توسط کلاینت، طی مراحل متفاوتی انجام میشه. درمورد Grant Type ها در قسمت بعدی مفصلا صحبت میکنیم. فعلا این رو درنظر بگیرید که در اینجا Grant Type رو Implicit در نظر گرفتیم.

دریافت Access Token طی مراحل زیر انجام میشه:

• کلاینت مشخصات درخواست مانند scopes ،client_id، redirect_uri و ... رو مشخص می کنه.
• کلاینت کاربر رو به Authorization Endpoint ریدایرکت می کنه.

GET https://accounts.google.com/o/oauth2/v2/auth?
   scope=https%3A//www.googleapis.com/auth/gmail.readonly
   &response_type=token
   &redirect_uri=http%3A//localhost:5000/auth/redirect
   &client_id={your-client-id}

• صفحه لاگین Authorization Server نمایش داده میشه و کاربر باید لاگین کنه.

پس از لاگین کردن، Consent Page به کاربر نمایش داده میشه و از کاربر خواسته میشه رضایت خودش رو از واگذاری این Scope ها به کلاینت اعلام کنه.

• درنهایت اگر کاربر تصمیم به واگذاری Scope ها بگیره، کاربر به redirect_uri ریدایرکت شده و Access Token رو به عنوان یک پارامتر در URL دریافت می کنه.

http://localhost:5000/auth/redirect#
   access_token={your-access-token}
   &token_type=Bearer
   &expires_in=3599
   &scope=https://www.googleapis.com/auth/gmail.readonly

کلاینت باید Access Token رو از URL اکسترکت کنه و آن را در جایی مثل Local Storage ذخیره کنه.

مرحله 3: استفاده از Access Token

زمانی که کلاینت Access Token معتبری رو در اختیار داره میتونه به Protected Resource های کاربر درخواست بده. دو نکته اصلی در این مرحله وجود داره:

• کلاینت فقط به منابعی می تونه دسترسی داشته باشه که در Scope ها درخواست داده و کاربر موافقت کرده.
• درهنگام ارسال درخواست باید Access Token دریافت شده از مرحله قبل در Request ارسال بشه.

درخواست دریافت شناسه آخرین ایمیل های کاربر:

GET https://www.googleapis.com/gmail/v1/users/me/messages?access_token={your-access-token}

پاسخ درخواست:

حال با داشتن شناسه آخرین ایمیل ها میتوانیم درخواستی برای گرفتن اطلاعات بیشتر هر پیام ارسال کنیم و به این ترتیب به آخرین ایمیل های کاربر دسترسی داشته باشیم.

منابع

https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow

https://developers.google.com/gmail/api/reference/rest/v1/users.messages