مقدمه OAuth

1- مقدمه

   در بیشتر برنامه‌های کاربردی، برای این که از کل امکانات آن‌ها استفاده کنیم، از ما می‌خواهند تا در آن برنامه ثبت‌نام کرده و یک حساب کاربری داشته باشیم. حتما برنامه‌هایی را دیده‌اید که قبل از ساختن اکانت، امکاناتی مانند مشاهده ی منو‌ها و تصاویر و برخی از اطلاعات ساده کاربران دیگر را در دسترس عموم قرار داده‌اند، اما وقتی وارد بخشی مثل آموزش آنلاین می‌شوید، همه مطالب را نشان نمی‌دهند و پیغامی‌مانند زیر را مشاهده می‌کنید:

   "این بخش از محتوا مخصوص کاربرانی است که ثبت‌نام کرده‌اند."

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

   اما این همه ماجرا نیست و این مثال را فقط برای آشنا شدن با مفهوم دسترسی محدود در استفاده از امکانات یک برنامه کاربردی، بیان کردیم. فرض کنید در یک برنامه کاربردی حساب کاربری دارید و اطلاعات کاملی از شما در آن برنامه ثبت شده است (برای مثال دارای یک اکانت Gmail باشید.) حالا می‌خواهید از یک برنامه کاربردی دیگر استفاده کنید، شاید نیاز باشد تا در آن برنامه نیز یک حساب کاربری ایجاد کنید. این اصلا برای کاربر خوشایند نیست که برای ایجاد اکانت جدید در تعداد زیادی برنامه، اطلاعات تکراری ثبت کند و همین‌طور نام‌های کاربری و پسوردهای آن‌ها را به خاطر بسپارد.

   راه‌کاری که احتمالا در برخی از برنامه‌ها دیده اید و عباراتی مانند زیر در آن نمایش داده می‌شود:

   “Sign in with Google”

   “Sign in with Facebook”

شکل‌های مختلفی از این عبارات را در تصاویر زیر می بینید:

   تصاویر بالا به این معنی است که در برنامه ی کاربردی، امکان لاگین کردن با استفاده از اکانت‌های google و facebook و ... فراهم می‌باشد. با وجود این امکان، دیگر نیازی به ساخت اکانت جدید نداریم. اما نکته‌ای وجود دارد، وقتی امکان استفاده از اکانت google را به یک برنامه کاربردی می‌دهیم، به این معنی است که به آن برنامه اجازه داده‌ایم تا به همه اطلاعات اکانت google ما دسترسی داشته باشد؟ برای مثال فرض کنید اطلاعات بانکی ما در اکانت google ثبت شده ولی نمی‌خواهیم آن‌ها را در اختیار برنامه کاربردی دیگری قرار دهیم و فقط بخواهیم به اطلاعات ساده ی پروفایل مانند نام و نام خانوادگی دسترسی داشته باشد. پس نیاز است از امکانی استفاده شود که بتوان با آن دسترسی محدودی به برنامه کاربردی داده شود.  

   اینجاست که موضوع OAuth به میان می‌آید. این که دقیقا این عبارت به چه معنی است را در این دوره بررسی خواهیم کرد، اما تنها برای این که مثال را کامل کنیم، می‌گوییم که OAuth اجازه لاگین کردن در یک برنامه ی کاربردی را با یک اکانت دیگر مانند google فراهم می‌کند اما با دسترسی محدود. دسترسی که برنامه ی کاربردی آن را از ما (کاربر نهایی) طلب می‌کند و ما باید آن را تایید ‌کنیم و google با توجه به مواردی که ما مشخص می‌کنیم، به آن برنامه دسترسی خواهد داد و اطلاعات را در اختیار آن برنامه ی کاربردی قرار می‌دهد. دقت داشته باشید در این جا کاربر است که تصمیم می‌گیرد آیا با استفاده از اکانت google وارد شود و یا اکانت جدید ایجاد کند.

2- مفاهیم و اصطلاحات پایه  

   در این بخش مفاهیمی‌ را که نیاز است قبل از ورود به مبحث OAuth بدانیم، به زبان ساده و به صورت مختصر بیان می‌کنیم. اگر با خواندن این موارد، هنوز مشکلاتی داشتید و یا آن‌ها را کاملا درک نکردید، پیشنهاد می‌کنیم قبل از ورود به مبحث اصلی، در مورد آن‌ها مطالعه کنید چرا که تشریح کامل آن‌ها هدف این دوره نبوده و ما تنها یک راهنمایی را به عنوان پیش نیاز‌های مبحث اصلی ارائه می‌دهیم.

  Authentication: در لغت به معنی احراز هویت می‌باشد و مفهوم آن، فرآیند مشخص شدن هویت کاربر می‌باشد مانند ورود به یک برنامه با استفاده از نام کاربری و رمز عبور.

  Authorization: در لغت به معنی مجوز یا اجازه قانونی می‌باشد. مفهوم آن عبارت است از فرآیند مشخص کردن اختیارات یا مجوز‌های قانونی کاربر  مانند اختیارات کاربر ادمین یا کاربر عادی یک برنامه. مثلا کاربر ادمین می‌تواند پست بگذارد ولی کاربر عادی اجازه پست گذاشتن نداشته و فقط می‌تواند در مورد آن پست، نظر دهد.

  API: کلمه API مخفف عبارت Application Programming Interface و به معنی رابط برنامه‌نویسی نرم‌افزار است. API ها رابط‌هایی نرم‌افزاری هستند که ارتباط بین نرم‌افزارهای مختلف را پیاده‌سازی می‌کنند. API همچون UI است با این تفاوت که به جای انسان، یک برنامه نرم‌افزاری قرار است با آن تعامل داشته باشد. در واقع، از آنجا که می‌توان واژه Interface را به «فصل مشترک» در فارسی ترجمه کرد، می‌توان گفت که API فصل مشترکی مابین دو نرم‌افزار است. (برای یادگیری عمیق تری از API به مقاله ی نوشته شده در سکان آکادمی مراجعه کنید)

1-2- اصطلاحات

   این بخش مانند یک فرهنگ واژه می‌باشد که در روال یادگیری این دوره، از این کلمات استفاده شده‌اند:

  Access Token: نشانه‌ ی دسترسی، چیزی است که برنامه‌ها برای درخواست API به نمایندگی از کاربر استفاده می‌کنند. Access Token، مجوز یک برنامه خاص برای دسترسی به قسمت‌های خاصی از داده‌های کاربر را نشان می‌دهد. Access Token ها باید در انتقال و ذخیره‌سازی، محرمانه نگه داشته شوند. تنها بخش‌هایی که باید به آن دسترسی داشته باشند، خود برنامه، سرور مجوز و سرور منبع هستند. برنامه باید اطمینان حاصل کند که محل ذخیره ی Access Token در دسترس سایر برنامه‌ها حتی در همان دستگاه نیست. Access Token فقط از طریق اتصال https قابل استفاده است، زیرا انتقال آن از طریق کانال های رمزگذاری نشده باعث می‌شود تا شخص ثالث برای رهگیری آن اقدام کند.

  Refresh Token: رشته‌ای است که با تمام شدن تاریخ انقضای یک access token، برای دریافت یک access token جدید استفاده می‌شود. همه API ها از refresh token استفاده نمی‌کنند.

  Grant: این کلمه به معنی اعطا کردن می‌باشد و در واقع منظور، اعطا کردن مجوز به یک برنامه کاربردی می‌باشد. Grant روش های مختلفی در oauth دارد که در ادامه به آن می‌پردازیم.

  Flow: روندی است که در هر روش Grant طی می‌شود تا به هدف که دسترسی به اطلاعات منابع باشد، برسیم.

  Consent: صفحه موافقت یا رضایت، همان صفحه‌ای است که از کاربر اجازه‌ی دادن دسترسی دادن به یک برنامه کاربردی را می‌گیرد.

  Client Identifier یا Client ID: یک رشته ی خاص برای شناسایی کلاینت توسط سرور می‌باشد. به بیان ساده‌تر شناسه عمومی برنامه‌ها است. با این که گفته شد عمومی می‌باشد اما بهتر است که توسط اشخاص ثالث قابل حدس و گمان نباشد، بنابراین در بسیاری از پیاده سازی‌ها از چیزی مانند یک رشته هگزا 32 کاراکتری استفاده می‌کنند. همچنین باید در بین کلیه کلاینت‌هایی که سرور مجوز از آن‌ها استفاده می‌کند، یکتا باشد.  

  Client Secret: یک راز شناخته شده فقط برای برنامه و سرور مجوز است و باید به اندازه کافی تصادفی باشد که قابل حدس و گمان نباشد. پس نباید از کتابخانه‌های UUID معمولی که اغلب از روی زمان و مک آدرس آن را می‌سازند، استفاده کرد. یک راه عالی برای ایجاد یک راز امن، استفاده از یک کتابخانه با رمزنگاری امن برای تولید یک مقدار 256 بیتی و تبدیل آن به یک هگزادسیمال است.

تفاوت Client Secret با Access Token در این است که از Client Secret برای درخواست دسترسی (مجوز) به منابع کاربر استفاده می‌شود در حالی که Access Token همان چیزی است که پس از اتمام authorization، توسط ارائه دهنده خدمات برای کلاینت صادر می‌شود و دسترسی کلاینت را نسبت به منابع کاربر خاص مشخص می‌کند. هر بار که کلاینت بخواهد به داده‌های کاربر دسترسی پیدا کند، Access Token را در درخواست به ارائه دهنده خدمات قرار می‌دهد.

  Authorization Code: کد مجوز یک کد موقتی است که کلاینت برای یک Access Token مبادله می‌کند. خود کد از سرور مجوز به دست می‌آید که در آن کاربر فرصتی پیدا می‌کند تا اطلاعات کلاینت را در درخواست ببیند و درخواست را تایید یا رد کند.

جمع‌بندی

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

  اگر در استفاده از این استاندارد تجربه ای یا پیشنهادی دارید با ما در میان بگذارید .