در چشمانداز مدرن توسعه برنامه، امنیت تنها یک ویژگی نیست؛ بلکه پایه و اساس آن است. برای توسعهدهندگانی که سیستمهای توزیعشده و پیچیده میسازند، مدیریت دستی هویت کاربر و کنترل دسترسی اغلب منجر به فاجعه میشود. اینجا است که OAuth 2.0 و OpenID Connect (OIDC) وارد عمل میشوند. اگرچه این دو پروتکل اغلب با هم استفاده میشوند، اما اهداف متمایزی دارند. اشتباه گرفتن آنها میتواند منجر به آسیبپذیریهای امنیتی حیاتی شود، از دسترسی غیرمجاز به دادهها تا دزدی جلسه (Session Hijacking).
این پست در تلاش است تا تفاوتها را روشن کند، نحوه عملکرد آنها را در سطح زیرساخت توضیح دهد و بینشهای عملی برای پیادهسازی امن آنها در برنامههای شما ارائه دهد.
درک تمایز: مجوزدهی در مقابل احراز هویت
برای تسلط بر این پروتکلها، باید ابتدا بفهمید هر کدام چه مشکلی را حل میکنند. به یک باشگاه با منطقه VIP و سیستم عضویت فکر کنید.
OAuth 2.0 یک چارچوب مجوزدهی (Authorization) است. این پروتکل روشی برای دسترسی محدود به منابع میزبان فراهم میکند. در مثال ما، OAuth بازوبندی است که پس از اثبات هویت خود در ورودی دریافت میکنید و به شما اجازه میدهد وارد سالن VIP شوید و از بار پریمیوم نوشیدنی بنوشید. این پروتکل به این سوال پاسخ میدهد: "این برنامه مجاز است به نمایندگی از کاربر چه کاری انجام دهد؟"
OpenID Connect (OIDC) یک لایه احراز هویت (Authentication) روی OAuth 2.0 است. این پروتکل اطلاعات هویتی را فراهم میکند. در مثال ما، OIDC کارت شناسایی است که توسط نگهبان بررسی میشود تا تأیید کند شخصی که وارد میشود واقعاً همان کسی است که ادعا میکند. این پروتکل به این سوال پاسخ میدهد: "این کاربر کیست؟"
استفاده تنها از OAuth 2.0 برای ورود به سیستم یک الگوی ضد (Anti-pattern) رایج است. اگرچه این پروتکل به شما امکان میدهد کاربر را با شناسه کاربری او شناسایی کنید، اما بدون ادعاهای اضافی ارائه شده توسط OIDC، یکپارچگی آن هویت را تضمین نمیکند.
نحوه عملکرد OpenID Connect
OIDC با افزودن یک id_token، که یک توکن وب JSON (JWT) است و توسط ارائهدهنده هویت (IdP) امضا شده است، OAuth 2.0 را گسترش میدهد. این توکن شامل ادعاها (Claims) درباره رویداد احراز هویت است، مانند شناسه موضوع، صادرکننده، مخاطب و زمان انقضا.
رایجترین جریان (Flow) برای برنامههای تکصفحهای (SPAs) و برنامههای موبایل، جریان کد مجوز با PKCE (کل اثبات برای تبادل کد) است. PKCE برای مشتریان عمومی (Public Clients) ضروری است تا از حملات دستکاری کد مجوز جلوگیری کند.
در اینجا نمایش سادهسازیشدهای از پارامترهای درخواست مجوز OAuth 2.0 آورده شده است:
GET https://auth.example.com/authorize
?response_type=code
&client_id=your_client_id
&redirect_uri=https://your-app.com/callback
&scope=openid profile email
&state=random_state_string
&code_challenge=e7b4...
&code_challenge_method=S256به پارامتر scope=openid توجه کنید. این سیگنالی به IdP است که شما در حال آغاز جریان OIDC هستید، نه فقط یک درخواست مجوز استاندارد OAuth2. پاسخ شامل هر دو توکن دسترسی (برای دسترسی به API) و توکن ID (برای هویت) خواهد بود.
بهترین شیوههای امنیتی
پیادهسازی صحیح این پروتکلها نیازمند پایبندی سختگیرانه به استانداردهای امنیتی است. در اینجا سه اصل غیرقابل مذاکره آورده شده است:
- همیشه توکن ID را اعتبارسنجی کنید: به توکن کورکورانه اعتماد نکنید. امضا را با استفاده از کلیدهای عمومی IdP (که از طریق نقطه پایانی
/.well-known/openid-configurationبه دست میآید) بررسی کنید. اطمینان حاصل کنید که ادعاهایiss(صادرکننده) وaud(مخاطب) با انتظارات شما مطابقت دارند. - از HTTPS در همه جا استفاده کنید: کدهای مجوز و توکنها هرگز نباید از طریق کانالهای رمزنگارینشده منتقل شوند. این یک الزام پایه است، نه یک گزینه.
- ذخیرهسازی مناسب توکن را پیادهسازی کنید: برای SPAs، توکنها را در حافظه ذخیره کنید، نه در localStorage یا sessionStorage که در معرض حملات XSS هستند. برای برنامههای سمت سرور، از کوکیهای HTTP-only و Secure استفاده کنید.
نتیجهگیری
OAuth 2.0 و OpenID Connect ابزارهای قدرتمندی هستند که وقتی به درستی درک و پیادهسازی شوند، به توسعهدهندگان اجازه میدهند راهحلهای هویتی امن و مقیاسپذیر بسازند بدون اینکه نیاز باشد چرخ را از نو اختراع کنند. با در نظر گرفتن OAuth به عنوان یک پروتکل مجوزدهی و OIDC به عنوان یک پروتکل احراز هویت، اطمینان حاصل میکنید که برنامههای شما یکپارچگی هویت کاربران را حفظ کرده و دسترسی مناسب به منابع را اعطا میکنند. با ادامه تکامل وب، تسلط بر این استانداردها همچنان یک مهارت حیاتی برای هر توسعهدهنده برنامه جدی است.