پروتکل SAML (Security Assertion Markup Language) که سال‌ها ستون فقرات سیستم‌های احراز هویت در سازمان‌های بزرگ و محیط‌های آکادمیک بوده است، اکنون به دلیل پیچیدگی‌های بیش از حد و نقص‌های بنیادین در طراحی، به یک ریسک امنیتی تبدیل شده است. با ظهور مدل‌های مدرن مانند OpenID Connect (OIDC)، نیاز به بازنگری در استفاده از SAML بیش از پیش احساس می‌شود.
بنیان‌های متزلزل: مشکل XML
یکی از بزرگ‌ترین نقاط ضعف SAML، اتکای آن به زبان XML است. برخلاف JSON که ساختاری ساده دارد، XML بسیار پیچیده است و تاریخچه‌ای طولانی از آسیب‌پذیری‌های بحرانی دارد. کتابخانه‌های SAML برای عملکرد صحیح باید بتوانند در برابر حملاتی نظیر XXE، SSRF (از طریق DTD retrieval) و XPath Injection مقاومت کنند. پیچیدگی XML باعث شده تا اکثر پیاده‌سازی‌های SAML از کتابخانه‌های قدیمی و پیچیده‌ای مانند libxmlsec استفاده کنند که تحلیل و بررسی امنیتی آن‌ها بسیار دشوار است.
چالش‌های فنی و حفره‌های امنیتی
- Canonicalization (C14N): برای اینکه امضای دیجیتال در XML معتبر بماند، داده‌ها باید به یک فرمت استاندارد تبدیل شوند. تفاوت در نحوه تفسیر این فرمت بین سرویس‌دهنده (IdP) و سرویس‌گیرنده (SP)، منجر به بروز Parser Differential می‌شود که مهاجمان می‌توانند از آن برای دور زدن احراز هویت استفاده کنند.
- Enveloped Signatures: در SAML، امضا درون خود داده‌ها قرار می‌گیرد (Enveloped). این ساختار باعث می‌شود دستیابی به یک نمایش بایت-به-بایت دقیق از داده‌ها در هنگام تغییر یا اعتبارسنجی بسیار دشوار شود.
- حملات XSW: حملات XML Signature Wrapping یکی از شناخته‌شده‌ترین روش‌های شکستن SAML هستند که اجازه می‌دهند مهاجم با تغییر ساختار XML، هویت خود را جعل کرده و به عنوان کاربر دیگر وارد سیستم شود.
طراحی «همه-در-یکی» و صلبیت پروتکل (Ossification)
SAML بر اساس متدولوژی Waterfall و توسط کمیته‌های مختلف طراحی شد که منجر به ایجاد یک پروتکل «Kitchen-sink» گردید؛ یعنی ویژگی‌های بسیار زیادی به آن اضافه شد که در عمل ۹۹٪ پیاده‌سازی‌های مدرن از تنها ۱۰٪ این قابلیت‌ها استفاده می‌کنند. این حجم از پیچیدگی بلااستفاده، سطح حمله (Attack Surface) را افزایش می‌دهد.
علاوه بر این، SAML برای دوران VPNها و شبکه‌های قطعه‌بندی شده طراحی شده بود و نتوانست خود را با انقلاب موبایل، اپلیکیشن‌های تک‌صفحه‌ای (SPA) و معماری‌های Zero Trust تطبیق دهد. در مقابل، OIDC به صورت ارگانیک رشد کرده و با استانداردهایی مانند PKCE و DPoP، امنیت را در لایه‌های انتقال (Transport Layer) و محیط‌های مدرن تضمین می‌کند.
مسیر مهاجرت به OIDC
برای سازمان‌ها و توسعه‌دهندگانی که همچنان از SAML استفاده می‌کنند، توصیه می‌شود به تدریج به سمت OpenID Connect حرکت کنند. OIDC نه تنها ساده‌تر است و از JSON استفاده می‌کند، بلکه با استانداردهای وب مدرن سازگاری کامل دارد. برای ارائه‌دهندگان هویت (IdP)، بهترین استراتژی تعریف یک برنامه بازنشستگی (Deprecation Plan) برای SAML و انتقال تدریجی مشتریان به پیکربندی‌های OIDC است.
