OAuth و PKCE چیستند و چرا نباید رمز سرویس‌ها را به هوش مصنوعی بدهیم؟
OAuth دسترسی محدود و قابل لغو ایجاد می‌کند و PKCE از سرقت کد مجوز جلوگیری می‌کند. این راهنما اتصال امن ابزارهای کسب‌وکار به هوش مصنوعی را به زبان ساده توضیح می‌دهد.
برای اینکه هوش مصنوعی بتواند از یک فروشگاه، حسابداری، سرویس ابری یا ابزار داخلی استفاده کند، باید راهی برای احراز هویت و تعیین سطح دسترسی وجود داشته باشد. ساده‌ترین راه ظاهری این است که رمز عبور یا API Key را مستقیماً به برنامه بدهیم؛ اما این روش معمولاً کنترل‌پذیری، قابلیت لغو و امنیت کافی ندارد.
OAuth به‌جای تحویل رمز اصلی، یک مجوز محدود و قابل لغو می‌سازد. PKCE نیز کمک می‌کند کد مجوز در مسیر اتصال قابل سوءاستفاده نباشد.
OAuth چیست؟
OAuth 2.0 چارچوبی برای اعطای دسترسی محدود به یک برنامه است. کاربر در سرویس اصلی وارد می‌شود، محدوده دسترسی را می‌بیند و اجازه می‌دهد برنامه ثالث بدون دریافت رمز عبور اصلی، توکن مناسب بگیرد.
برای مثال هنگام اتصال WordPress به وصلک، کاربر در WordPress احراز هویت می‌شود و به اتصال مشخصی اجازه می‌دهد از ابزارهای مجاز استفاده کند. وصلک نباید رمز ورود WordPress را دریافت یا نگهداری کند.
چهار نقش اصلی در OAuth
- Resource Owner: شخص یا سازمانی که داده و دسترسی متعلق به اوست.
- Client: برنامه‌ای که درخواست دسترسی می‌کند؛ مثلاً وصلک.
- Authorization Server: بخشی که ورود و صدور مجوز را مدیریت می‌کند.
- Resource Server: API یا سرویسی که داده و عملیات را ارائه می‌دهد.
Access Token چیست؟
Access Token مدرکی است که Client هنگام درخواست به Resource Server ارائه می‌کند. این توکن معمولاً عمر و Scope مشخص دارد و باید خارج از دسترس مدل، مرورگرهای نامطمئن و لاگ‌های عمومی نگهداری شود.
توکن جای رمز اصلی را نمی‌گیرد؛ یک مجوز مستقل است که می‌تواند محدود، منقضی یا Revoke شود. اگر طراحی درست باشد، قطع یک اتصال نیازی به تغییر رمز اصلی سرویس ندارد.
Scope چیست؟
Scope محدوده مجوز را مشخص می‌کند. یک اتصال ممکن است فقط اجازه خواندن سفارش‌ها را داشته باشد، در حالی که اتصال دیگری اجازه ویرایش محصول را هم دارد. Scope خوب باید حداقلی، قابل فهم و متناسب با نیاز واقعی باشد.
عبارت کلی «دسترسی کامل» برای اتصال هوش مصنوعی خطرناک است. بهتر است ابزارها و عملیات خواندن، نوشتن، حذف و مالی جدا شوند.
Authorization Code Flow چگونه کار می‌کند؟
- کاربر از پنل برنامه ثالث، اتصال را شروع می‌کند.
- مرورگر به Authorization Server سرویس مقصد می‌رود.
- کاربر وارد می‌شود و دسترسی را تأیید می‌کند.
- سرویس یک Authorization Code کوتاه‌عمر به Callback ثبت‌شده برمی‌گرداند.
- Client کد را از مسیر سرور با Token Endpoint مبادله می‌کند.
- Access Token صادر می‌شود و برای فراخوانی API استفاده می‌گردد.
Authorization Code نباید مثل توکن دائمی تلقی شود. این کد کوتاه‌عمر و یک‌بارمصرف است و فقط باید در Callback دقیق و از پیش ثبت‌شده پذیرفته شود.
PKCE چیست؟
PKCE مخفف Proof Key for Code Exchange است. Client پیش از شروع اتصال یک رشته تصادفی به نام Code Verifier می‌سازد و نسخه مشتق‌شده آن، Code Challenge، را همراه درخواست مجوز می‌فرستد.
هنگام مبادله Authorization Code، Client باید Code Verifier اصلی را ارائه کند. Authorization Server آن را با Challenge قبلی تطبیق می‌دهد. بنابراین اگر مهاجم فقط کد مجوز را رهگیری کند، بدون Verifier نمی‌تواند آن را به توکن تبدیل کند.
چرا PKCE لازم است؟
RFC 7636 برای کاهش خطر Authorization Code Interception طراحی شد. امروزه PKCE فقط برای اپلیکیشن موبایل مفید نیست؛ در جریان‌های مدرن OAuth، استفاده از آن یک کنترل پایه و مهم محسوب می‌شود.
S256 یعنی چه؟
در روش S256، Code Challenge از هش SHA-256 روی Code Verifier ساخته می‌شود. این روش از ارسال مستقیم Verifier در مرحله اول جلوگیری می‌کند و نسبت به روش Plain انتخاب امن‌تری است.
State چه نقشی دارد؟
پارامتر State درخواست شروع اتصال را به Callback مربوط می‌کند و برای مقابله با CSRF و جابه‌جایی نشست اهمیت دارد. State باید تصادفی، کوتاه‌عمر، یک‌بارمصرف و به نشست کاربر متصل باشد.
PKCE و State جای هم را نمی‌گیرند. PKCE مالکیت جریان کد را اثبات می‌کند و State ارتباط Callback با درخواست اولیه و نشست را کنترل می‌کند.
Redirect URI چرا باید دقیق باشد؟
Callback باید از قبل ثبت شود و Authorization Server آن را با تطبیق دقیق بررسی کند. Redirect عمومی یا قابل تغییر می‌تواند کد مجوز را به مقصد مهاجم بفرستد. بهترین شیوه امنیتی OAuth روی Exact Redirect URI و جلوگیری از Open Redirect تأکید دارد.
بهترین رویه امنیتی OAuth 2.0؛ RFC 9700
Refresh Token چیست؟
Access Token معمولاً کوتاه‌عمر است. Refresh Token می‌تواند برای دریافت Access Token جدید استفاده شود، بدون اینکه کاربر هر بار دوباره وارد شود. چون Refresh Token عمر و قدرت بیشتری دارد، باید با حفاظت قوی‌تر، Rotation و امکان Revoke نگهداری شود.
همه جریان‌ها Refresh Token ندارند. برای نمونه در Client Credentials، سرویس معمولاً توکن کوتاه‌عمر جدید می‌گیرد و کاربری در مرورگر حضور ندارد.
Client Credentials چه زمانی استفاده می‌شود؟
این Grant برای ارتباط سروربه‌سرور است؛ جایی که خود یک سرویس با هویت سازمانی به سرویس دیگر دسترسی می‌گیرد. اتصال Grafana به API مانیتورینگ وصلک نمونه‌ای از چنین مدلی است.
Client Credentials برای واگذاری دسترسی از طرف یک کاربر مناسب نیست. در آن حالت Authorization Code به‌همراه PKCE و Scopeهای کاربرمحور انتخاب منطقی‌تری است.
چرا نباید رمز سرویس را در ChatGPT وارد کنیم؟
- رمز اصلی معمولاً سطح دسترسی گسترده‌تری از نیاز دارد.
- نمی‌توان دسترسی همان اتصال را مستقل از حساب اصلی به‌سادگی لغو کرد.
- رمز ممکن است در گفتگو، History، Screenshot یا لاگ کپی شود.
- مدل نباید مسئول نگهداری و انتخاب Secret باشد.
- تغییر عضو یا کلاینت AI نباید نیازمند تعویض رمز سرویس باشد.
- Audit دقیق اینکه کدام اتصال چه کاری انجام داده دشوار می‌شود.
API Key همیشه بد است؟
خیر. بعضی سرویس‌ها فقط API Key ارائه می‌کنند و این کلید می‌تواند محدود و مناسب باشد. مشکل زمانی است که کلید در متن گفتگو قرار گیرد، Scope بیش از حد داشته باشد یا بین چند کاربر مشترک شود.
اگر API Key لازم است، باید در Vault رمزگذاری‌شده ذخیره شود، فقط در سمت سرور استفاده شود، در لاگ Mask گردد و Rotation و Revoke مشخص داشته باشد.
OAuth چه چیزی را حل نمی‌کند؟
- OAuth تضمین نمی‌کند خود ابزار یا سرور مقصد امن است.
- توکن معتبر به معنی مجازبودن هر عملیات نیست؛ سرویس باید مجوز منبع را هم بررسی کند.
- OAuth جلوی Prompt Injection را به‌تنهایی نمی‌گیرد.
- Scope بد یا بیش از حد همچنان خطرناک است.
- عملیات مالی و مخرب ممکن است علاوه بر OAuth به تأیید انسانی نیاز داشته باشند.
یک جریان امن برای اتصال AI
- اتصال از پنل قابل اعتماد و توسط عضو مجاز شروع شود.
- Authorization Code با PKCE S256 و State یک‌بارمصرف اجرا شود.
- Callback دقیق، HTTPS و از پیش ثبت‌شده باشد.
- Tokenها در سمت سرور و خارج از Context مدل ذخیره شوند.
- ابزارها بر اساس Scope و نقش عضو محدود شوند.
- هر فراخوانی مجوز را دوباره بررسی کند.
- عملیات حساس تأیید، Idempotency و Audit داشته باشند.
- قطع اتصال، Rotation و Revoke از پنل ممکن باشد.
اتصال در وصلک چگونه مدل می‌شود؟
در وصلک، Credential سرویس از اتصال ChatGPT یا کلاینت AI جداست. کانکتور سرویس با OAuth یا روش امن پشتیبانی‌شده متصل می‌شود و MCP Gateway فقط ابزارهای مجاز را به عضو و کلاینت نشان می‌دهد.
برای کانکتورهایی مانند PrestaShop و WordPress، اتصال از پنل وصلک آغاز می‌شود و PKCE، Callback ثابت و بررسی مجوزهای مقصد بخشی از جریان هستند. ابزارهای جدید نیز نباید بدون بازبینی به Scope اتصال موجود اضافه شوند.
اتصال ChatGPT به PrestaShop و WooCommerce
چک‌لیست بررسی یک اتصال OAuth
- Authorization Server و Client ID مشخص و معتبرند؟
- Redirect URI دقیق و HTTPS است؟
- PKCE با S256 استفاده می‌شود؟
- State به نشست متصل و یک‌بارمصرف است؟
- Scopeها حداقلی و قابل توضیح‌اند؟
- Tokenها کجا و با چه رمزگذاری ذخیره می‌شوند؟
- انقضا، Refresh، Rotation و Revoke چگونه کار می‌کنند؟
- بعد از حذف عضو یا تغییر نقش، دسترسی فوراً بازبینی می‌شود؟
- عملیات حساس مجوز و تأیید مستقل دارند؟
جمع‌بندی
OAuth روشی برای واگذاری دسترسی است، نه اشتراک‌گذاری رمز. PKCE نیز تضمین می‌کند کسی که جریان اتصال را آغاز کرده، هنگام تبدیل Code به Token مدرک لازم را در اختیار دارد. این دو همراه با Scope حداقلی، Callback دقیق و ذخیره امن Token، پایه یک اتصال حرفه‌ای به ابزارهای هوش مصنوعی هستند.
هوش مصنوعی باید ابزار را ببیند، نه Secret را؛ و باید مجوز محدود را استفاده کند، نه رمز اصلی حساب را.
