Messages

Home Login Logout

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

گاهی سردرگمی‌های زیادی بین روش‌ها OpenID و OAuth2 برای طراحان و کاربران سیستم‌ها ایجاد می‌شود به خصوص زمانی که نیاز است تعیین کرد کدام روش بهترین انتخاب برای یک کاربرد خاص است. در نتیجه این سردگمی‌ها سیستم‌های غیر امن زیادی توسعه داده شده و روانه بازار می‌شوند که تنها به یک توافق با مشتریان بر سر داده‌ها بسنده می‌کنند.

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

  • یک مرور کلی بر هر یک از پروتکل‌ها
  • اطلاعاتی در مورد توکن‌هایی که در هر یک از این پروتکل‌ها استفاده می‌شود
  • پیشنهاد در مورد این که در چه شرایطی از کدام پروتکل استفاده شود

در این مقاله با تشریح این که چرا باید از توکن دسترسی برای مدیریت و امن کردن API استفاده کرد مطالب خود را شروع خواهیم کرد.

دو روش فنی مکمل

در حالت کلی باید گفت OpenID به این مسئله می‌پردازد که درخواست دهنده چه کسی است به بیان دیگر کاربر اصلی این روش احراز هویت است. OAuth2 تعیین می‌کند که هر فرد چه دسترسی‌هایی دارد و چه کارهایی می‌تواند در سیستم انجام دهد به بیان دیگر کاربرد این روش احراز اصالت است.

روش OAuth2 برای ضمانت احراز اصالت (کنترل دسترسی) استفاده می‌شود. این روش به شما این امکان را می‌دهد که با استفاده از یک نرم‌افزار جدید به اطلاعات خود روی وب سایت دسترسی داشته باشید بدون اینکه نیازی به استفاده از گذرواژه در هر دو نرم‌افزار داشته باشید. روش OAuth2 تنها با در نظر گرفتن روش‌های کنترل دسترسی و احراز اصالت طراحی شده و در فرآیند طراحی راهکارهای احراز هویت را بررسی نکرده است. به بیان دیگر این سیستم راهکاری برای احراز اصالت کاربران در نظر نگرفته و روشی را برای سیستم‌ها ارائه نمی‌کند.

سیستم OpenID بر اساس راهکارهایی که در OAuth2 طراحی شده. این روش به شما امکان احراز اصالت و همچنین اشتراک گذاری اطلاعات پروفایل کاربر بدون نیاز به گذرواژه را می‌دهد.

نمونه‌ای از کاربردهای این پروتکل‌ها

فرض کنید که یک نرم‌افزار وجود دارد که فهرست کارهایی که شما باید انجام دهید را مدیریت می‌کند. برای استفاده از این نرم‌افزار شما از گذرواژهای که در سیستم‌های گوگل دارید استفاده می‌کنید. حال شما می‌خواهید به این نرم‌افزار اجازه دسترسی به تقویم خود در سیستم‌های گوگل را بدهید و با این کار امکان اضافه کردن رویداد به سیستم تقویم گوگل خود را از نرم افزار مدیریت کارهای خود فراهم کنید.

بخشی از سیستم که به شما امکان ورود به نرم افزار مدیریت کارها را با استفاده گذرواژه گوگل شما را می‌دهد با استفاده از OpenID انجام می‌شود. به بیان دیگر احراز هویت شما با استفاده پروتکل OpenID انجام می‌شود. اما آن بخشی از سیستم که می‌خواهد به منابع شما در سرورهای گوگل دسترسی پیدا کند با استفاده از پروتکل OAuth2 بررسی خواهد شد.

نقش توکن‌ها

اگر در متن‌های بالا دقت کرده باشید در برخی از موارد تاکید شده که احراز اصالت و احراز هویت بدون اشتراک گذاشتن گذرواژه انجام خواهد شد. اما پرسش اصلی این است که چطور بدون استفاده از گذرواژه می‌توان این مفاهیم را مدیریت کرد؟

در حقیقت هر دو این پروتکل‌ها با استفاده از اشتراک گذاشتن توکن (یک رشته رمز شده و کدگذاری شده)  عمل می‌کنند و نیاز به اشتراک گذرواژه‌ها ندارند.

در پروتکل OpenID به هر کاربر تعداد توکن داده می‌شود که به آنها توکن‌های شناسه یا ID Token گفته می‌شود در حالی که در پروتکل OAuth2 به کاربر توکن‌هایی داده می‌شود که به آنها توکن‌های دسترسی یا Access Token گفته می‌شود. این نام گذاری‌ها بر اساس کاربردهای این توکن‌ها در نظر گرفته شده است.

چگونه توکن‌ها را استفاده کنیم

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

سیستم‌های ما قبل از اینکه هر توکن شناسه را استفاده کند آن را از نظر صحت بررسی کرده و در نهایت بر اساس اطلاعات توکن شناسه و اطلاعات موجود کاربری تعیین می‌کند که فرد مورد نظر چه کسی است. این کار با استفاده از سیستم‌های بسیار امن و سریع انجام می‌شود.

نکته اینکه هیچ لزومی ندارد که در سیستم‌ها از توکن‌های JWT برای شناسه استفاده شود اما در سیستم ما از این مدل توکن استفاده شده و برای استفاده از API سیستم به کار می‌رود.

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

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

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

نرم افزار مدیریت کار توکن دسترسی را از گوگل درخواست می‌کند و این توکن را برای کارهای خود استفاده می‌کند. این توکن بدون دیکد شدن و یا تجزیه شدن در تمام فراخوانی‌ها توسط سیستم مدیریت کار استفاده می‌شود و دسترسی‌های ما به منابع کاربر در سیستم گوگل را تضمین می‌کند.

چطور توکن‌ها را استفاده نکنیم

تا پیش از این در این مورد صحبت کردیم که چطور توکن‌های ایجاد شده در سیستم‌های OpenID و OAuth2 را در کارهای خود استفاده کنیم. اجازه دهید که در این بخش به این موضوع به پردازیم که در چه حالت‌هایی نباید از این توکن‌ها استفاده کرد.

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

مقایسه توکن‌ها

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

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

{
 "iss": "http://YOUR_AUTH0_DOMAIN/",
 "sub": "auth0|123456",
 "aud": "YOUR_CLIENT_ID",
 "exp": 1311281970,
 "iat": 1311280970,
 "name": "Jane Doe",
 "given_name": "Jane",
 "family_name": "Doe",
 "gender": "female",
 "birthdate": "0000-10-31",
 "email": "janedoe@example.com",
 "picture": "http://example.com/janedoe/me.jpg"
}

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

نمونه‌ای از توکن دسترسی نیز در زیر آمده:

{
 "iss": "https://YOUR_AUTH0_DOMAIN/",
 "sub": "auth0|123456",
 "aud": [
   "my-api-identifier",
   "https://YOUR_AUTH0_DOMAIN/userinfo"
 ],
 "azp": "YOUR_CLIENT_ID",
 "exp": 1489179954,
 "iat": 1489143954,
 "scope": "openid profile email address phone read:appointments"
}

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

در برخی موارد نیاز است که اطلاعات بیشتری در این توکن‌ها برای تعیین نوع دسترسی وجود داشته باشد. بنابر این طبیعی است که در توکن دسترسی نیز اطلاعات برای تعیین کاربر نیز وجود دارد تا بتوان داده‌ها و بخش‌های قابل دسترسی با استفاده از این توکن را تعیین کرد.

LocalTheme

Help