در فضای امنیتی برنامههای مدرن، موضوعی کمتر وجود دارد که گیجکنندهتر یا آسیبپذیرتر از رابطه بین OAuth 2.0 و OpenID Connect (OIDC) باشد. اگرچه اغلب با هم نام برده میشوند، اما اهداف کاملاً متفاوتی دارند. OAuth 2.0 یک چارچوب مجوزدهی است، در حالی که OpenID Connect لایهای برای احراز هویت است که بر روی آن ساخته شده است. درک این تمایز نه تنها یک بحث آکادمیک است، بلکه برای ساخت برنامههای امن، مقیاسپذیر و کاربرپسند ضروری است.
فیل مجوزدهی: OAuth 2.0
در هسته خود، OAuth 2.0 برای حل یک مشکل خاص طراحی شده است: چگونه یک برنامه شخص ثالث میتواند به منابع کاربر در یک سرویس دیگر دسترسی داشته باشد، بدون اینکه با اعتبارنامههای کاربر سروکار داشته باشد؟ آن را مانند دادن کلید امانی به پارکبان خودروی خود در نظر بگیرید. شما کلید اصلی خود (نام کاربری و رمز عبور) را تحویل نمیدهید؛ بلکه کلیدی با دسترسی محدود را میدهید که فقط در را باز میکند و موتور را روشن میکند.
OAuth 2.0 چهار نقش اصلی را تعریف میکند:
- مالک منبع: کاربری که مالک دادهها است.
- کلاینت: برنامهای که درخواست دسترسی دارد.
- سرور مجوزدهی: سرویسی که کاربر را احراز هویت میکند و توکنها را صادر میکند (مانند Google، GitHub).
- سرور منبع: سرویسی که دادههای محافظتشده را میزبانی میکند.
هنگامی که کاربر اجازه میدهد، سرور مجوزدهی یک توکن دسترسی صادر میکند. این توکن یک رشته است که کلاینت آن را به سرور منبع ارائه میدهد تا دسترسی کسب کند. نکته مهم این است که توکن دسترسی هیچ اطلاعات هویتی کاربری را شامل نمیشود—این صرفاً کلیدی برای باز کردن منابع است.
لایه هویت: OpenID Connect
اگر OAuth 2.0 با «دسترسی» سروکار دارد، OpenID Connect با «هویت» سروکار دارد. OIDC یک لایه هویت است که بر روی پروتکل OAuth 2.0 ساخته شده است. این پروتکل نوع توکن جدیدی را معرفی میکند: توکن ID.
توکن ID یک توکن وب JSON (JWT) است که ادعاها (claims) مربوط به رویداد احراز هویت را شامل میشود—مانند اینکه چه کسی، چه زمانی و از کجا وارد شده است. وقتی عبارت «ورود با Google» یا «ورود با GitHub» را میبینید، در حال مشاهده OpenID Connect در عمل هستید. ارائهدهنده OIDC کاربر را احراز هویت میکند و سپس یک توکن ID را به کلاینت برمیگرداند که هویت کاربر را تأیید میکند.
تفاوتهای کلیدی در یک نگاه
| ویژگی | OAuth 2.0 | OpenID Connect |
|---|---|---|
| هدف | مجوزدهی (دسترسی) | احراز هویت (هویت) |
| نوع توکن | توکن دسترسی | توکن ID (JWT) |
| مورد استفاده | خواندن تقویم کاربر | تأیید هویت کاربر |
پیادهسازی عملی: جریان کد مجوزدهی
برای برنامههای وب، جریان توصیه شده، جریان کد مجوزدهی با PKCE (کلید اثبات برای تبادل کد) است. این جریان تضمین میکند که حتی اگر کد مجوزدهی دستچین شود، مهاجم نمیتواند از آن بدون راز کلاینت (یا تأییدیه PKCE) استفاده کند.
در اینجا یک مثال مفهومی از ساختار درخواست آورده شده است:
GET /authorize?
response_type=code&
client_id=YOUR_CLIENT_ID&
redirect_uri=https://yourapp.com/callback&
scope=openid profile email&
code_challenge=YOUR_CODE_CHALLENGE&
code_challenge_method=S256
HTTP/1.1در این مثال، به پارامتر scope=openid توجه کنید. این سیگنالی به سرور مجوزدهی است که شما درخواست احراز هویت از طریق OIDC دارید، نه فقط مجوزدهی. بدون این scope، شما فقط یک توکن دسترسی برای دسترسی به API دریافت میکنید، نه یک توکن ID برای تأیید هویت.
بهترین شیوهها برای امنیت
پیادهسازی صحیح این پروتکلها با چالشهای زیادی همراه است. همیشه در صورت امکان توکنها را در کوکیهای httpOnly ذخیره کنید تا از حملات Script بین سایتی (XSS) برای سرقت آنها جلوگیری شود. هرگز توکنها را در حافظه محلی (local storage) ذخیره نکنید، مگر اینکه واقعاً ضروری باشد، زیرا جاوااسکریپت میتواند آن را بخواند. علاوه بر این، همیشه امضای توکن ID را در سمت سرور اعتبارسنجی کنید و ادعاهای iss (صادرکننده) و aud (مخاطب) را بررسی کنید تا اطمینان حاصل کنید که توکن توسط یک ارائهدهنده مورد اعتماد برای برنامه خاص شما صادر شده است.
نتیجهگیری
OAuth 2.0 و OpenID Connect ابزارهای قدرتمندی هستند که در صورت درک و پیادهسازی صحیح، میتوانند به طور قابل توجهی وضعیت امنیتی برنامه شما را بهبود بخشند. با تفکیک نگرانیها—استفاده از OAuth برای دسترسی و OIDC برای هویت—شما یک پایه قوی برای برنامههای وب مدرن ایجاد میکنید. به عنوان توسعهدهندگان، مسئولیت ما فراتر از کپی-پیست کردن کد است و باید به طور واقعی پیامدهای امنیتی هر توکنی که صادر و اعتبارسنجی میکنیم را درک کنیم.