مقدمه
در بیشتر برنامه های کاربردی، برای این که از همه ی امکانات استفاده کنیم، از ما خواسته می شود در آن برنامه ثبت نام کرده و یک حساب کاربری داشته باشیم. به احتمال زیاد برنامه هایی را دیده اید که قبل از ساختن اکانت، امکاناتی مانند مشاهده ی منو‌ها و عکس ها و برخی از اطلاعات ساده ی کاربران دیگر را در دسترس عموم قرار داده‌اند، اما وقتی وارد بخشی مثل آموزش آنلاین می شوید، همه مطالب را نشان نمی دهند و پیغامی مانند زیر را مشاهده می کنید:
"این بخش از محتوا مخصوص کاربرانی است که ثبت نام کرده اند."
در کنار این پیغام، لینک لاگین (Login) و یا ساخت اکانت جدید (برای مثال Create account) نیز دیده می شود. زمانی که اکانت خود را ایجاد کنید، سطح دسترسی بیشتری پیدا خواهید کرد.
اما این همه ماجرا نیست و این مثال را فقط برای آشنا شدن با مفهوم دسترسی محدود در استفاده از امکانات یک برنامه ی کاربردی، بیان کردیم. فرض کنید در یک برنامه ی کاربردی حساب کاربری دارید و اطلاعات کاملی از شما در آن برنامه ثبت شده است (برای مثال دارای یک اکانت Gmail باشید.). حالا می خواهید از یک برنامه ی کاربردی دیگر استفاده کنید، شاید نیاز باشد تا در آن برنامه نیز یک حساب کاربری ایجاد کنید. این برای کاربر خوشایند نیست که در تعداد زیادی برنامه، اکانت های مختلف داشته و اطلاعات تکراری ثبت کند و همین طور نام های کاربری و پسوردهای آن ها را به خاطر بسپارد.
راه کار جالبی برای آن وجود دارد که به احتمال زیاد در برخی از برنامه ها دیده اید و عباراتی مانند زیر در آن ها نمایش داده می شود:
“Sign in with Google”
“Sign in with Facebook”
شکل های مختلفی از این عبارت ها را در تصویر های زیر می بینید:
شکل های بالا به این معنی است که در آن برنامه ی کاربردی، امکان لاگین کردن با استفاده از اکانت های google و facebook و ... وجود دارد. با وجود این امکان، دیگر نیازی به ساخت اکانت جدید نداریم. اما سوالی پیش می آید. وقتی امکان استفاده از اکانت google را به یک برنامه ی کاربردی می دهیم، به این معنی است که به آن برنامه اجازه داده ایم تا به همه ی اطلاعات اکانت google ما دسترسی داشته باشد؟
فرض کنید اطلاعات مهمی در اکانت google ما ثبت شده است. قصد داریم از یک سایت آموزشی استفاده کنیم که برای دیدن فایل های آموزشی نیاز به ثبت نام دارد. اگر بخواهیم با استفاده از اکانت google، در آن سایت لاگین کنیم، ممکن است آن سایت به همه ی اطلاعات ما دسترسی پیدا کند. ما فقط لازم است در آن سایت لاگین کنیم و نمی خواهیم اطلاعات دیگری در اختیار آن سایت بگذاریم. یعنی فقط می خواهیم به اطلاعات ساده ی پروفایل مانند نام و نام خانوادگی دسترسی داشته باشد. پس نیاز است از امکانی استفاده شود که بتوان، دسترسی محدودی به سایت آموزشی داد.
این جاست که موضوع جذابی به نامOAuth به میان می آید. این که دقیقا این عبارت به چه معنی است را در این دوره بررسی خواهیم کرد، اما تنها برای این که مثال را کامل کنیم، می گوییم کهOAuth اجازه لاگین کردن در یک برنامه ی کاربردی را با یک اکانت دیگر مانندgoogle فراهم می کند اما با دسترسی محدود. برنامه ی کاربردی، این دسترسی را از ما (کاربر نهایی) درخواست می کند و ما باید آن را تایید کنیم و google با توجه به مواردی که ما مشخص می کنیم، به آن برنامه دسترسی خواهد داد و اطلاعات را در اختیار آن برنامه ی کاربردی قرار می دهد. دقت داشته باشید در این جا کاربر است که تصمیم می گیرد، آیا با استفاده از اکانتgoogle وارد شود و یا اکانت جدید ایجاد کند.
مفاهیم و اصطلاحات پایه
قبل از ورود به مبحث OAuth، نیاز است با چند مفهوم آشنایی داشته باشیم که آن ها را در ادامه به زبان ساده و به صورت مختصر بیان می کنیم. اگر با خواندن این موارد، احساس کردید که نیاز به داشتن اطلاعات بیشتر در مورد آن ها دارید و یا آن ها را به طور کامل درک نکردید، پیشنهاد می کنیم کمی در مورد آن ها مطالعه کنید. توضیح کامل این موارد، هدف این دوره ی آموزشی نیست و فقط به عنوان پیش نیاز آن ها را برایتان تعریف می کنیم.
- Authentication: در لغت به معنی احراز هویت و مفهوم آن، فرآیند مشخص شدن هویت کاربر است، مانند ورود (login) به یک برنامه با استفاده از نام کاربری و رمز عبور.
- Authorization: در لغت به معنی مجوز یا اجازه ی قانونی است. مفهوم آن عبارت است از فرآیند مشخص کردن دسترسی ها یا مجوز‌های قانونی کاربر مانند دسترسی های کاربر ادمین (admin) یا کاربر عادی یک برنامه. برای مثال، کاربر ادمین می تواند پست (post) بگذارد ولی کاربر عادی اجازه پست گذاشتن نداشته و فقط می تواند در مورد آن پست، نظر دهد.
- API: کلمه API مخفف عبارت Application Programming Interface و به معنی رابط برنامه نویسی نرم افزار است. API ها، رابط هایی هستند که ارتباط بین نرم افزارهای مختلف را پیاده سازی می کنند. یک API مانند UI است با این تفاوت که به جای انسان، یک برنامه ی نرم افزاری قرار است با آن تعامل داشته باشد. اگر واژه ی Interface را در فارسی به "فصل مشترک" ترجمه کنیم، می توان گفت که API فصل مشترکی مابین دو نرم افزار است. (برای یادگیری بیشتر رویAPI می توانید به مقاله ی API چیست؟ در سکان آکادمی مراجعه کنید.)
اصطلاحات
در دوره ی آموزشی OAuth، از کلمه هایی که در زیر به عنوان فرهنگ واژه معرفی شده اند، استفاده خواهد شد. شاید در ابتدا می برایتان نامفهوم باشند اما در بخش های بعدی، بیشتر با آن ها سر و کار خواهیم داشت و درک بهتری از آن ها به دست خواهید آورد، پس نگران نباشید.
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 معمولی که اغلب از روی زمان و آدرس مک آن را می سازند، استفاده کرد. یک راه عالی برای ایجاد یک Client Secret، استفاده از یک کتابخانه با رمزنگاری امن برای تولید یک مقدار 256 بیتی و تبدیل آن به یک هگزا دسیمال است.
تفاوت Client Secret با Access Token در این است که از Client Secret برای درخواست دسترسی (مجوز) به اطلاعات کاربر استفاده می شود در حالی که Access Token همان چیزی است که پس از تمام شدن Authorization، ارائه دهنده ی خدمات برای کلاینت صادر و دسترسی کلاینت را نسبت به اطلاعات کاربر خاص، مشخص می کند. هر بار که کلاینت بخواهد به داده های کاربر دسترسی پیدا کند،Access Token را در درخواستی که به ارائه دهنده ی خدمات ارسال می کند، قرار می دهد.
Authorization Code
کد مجوز، یک کد موقتی است که کلاینت برای یک Access Token مبادله می کند. این کد از سرور مجوز به دست می آید که در آن کاربر فرصتی پیدا می کند تا اطلاعات کلاینت را در درخواست ببیند و درخواست دسترسی را تایید یا رد کند.
جمع‌بندی
در این فصل سعی کردیم مفاهیم پایه و اصطلاحاتی را که لازم است کمی در مورد آن ها بدانید، به صورت خلاصه برایتان بیان کنیم. مطالعه ی این مفاهیم برای آمادگی ورود به بخش های بعد است. اگر هر کدام از آن ها برایتان مشکل بود، نگران نباشید. در فصل های آینده، به اندازه کافی در مورد هر کدام صحبت خواهیم کرد و بر اساس مثال های کاربردی، به راحتی متوجه ی مفهوم هر کدام از آن ها خواهید شد.