OAuth چیست؟ «ورود با Google» و دسترسی تفویضی توضیح داده شده
OAuth یک استاندارد باز است که به یک کاربر اجازه می‌دهد دسترسی محدودی به حسابش در سرویس دیگری را به یک اپ بدهد، بدون اینکه رمز عبورش را تحویل دهد. وقتی روی «اتصال تقویم Google» کلیک می‌کنید و صفحه‌ای می‌بینید با پرسش «اجازه می‌دهید این اپ رویدادهای شما را ببیند؟»، این OAuth است. اپ توکنی فقط برای همان چیزی که تأیید کرده‌اید می‌گیرد، و هر زمان بخواهید می‌توانید آن را لغو کنید. همان سازوکار، با یک لایه اضافی به نام OpenID Connect، دکمه‌های «ورود با Google» و مشابه آن را تأمین می‌کند.
چرا OAuth وقتی با هوش مصنوعی می‌سازید اهمیت دارد
OAuth در دو موقعیت رایج هنگام ساختن اپ ظاهر می‌شود:
- ورود اجتماعی. می‌خواهید کاربرانتان به‌جای ساختن یک رمز دیگر با «ورود با Google» (یا Apple، Microsoft، GitHub) وارد شوند. ببینید چطور ورود را به اپ اضافه کنیم.
- اتصال به حساب‌های کاربران در سرویس‌های دیگر. اپ شما باید تقویم کاربر را بخواند، در حساب شبکه اجتماعی او پست بگذارد، فایل‌ها را از درایو ابری او بیاورد یا داده حسابداری‌اش را همگام کند.
در هر دو حالت ابزار ساخت با هوش مصنوعی می‌تواند کد را بنویسد، اما بعضی مراحل را فقط شما می‌توانید انجام دهید: ساختن یک اپ توسعه‌دهنده با ارائه‌دهنده، گرفتن client ID و client secret، ثبت URLهای بازگشت و، برای بعضی مجوزها، گذراندن بررسی ارائه‌دهنده. دانستن نحوه کار OAuth این مراحل و خطاهایی را که تولید می‌کنند کمتر مرموز می‌کند. برای تصویر بزرگ‌تر از ورود، ببینید احراز هویت چیست.
یک مثال روزمره
به کلید کارت هتل فکر کنید. موقع تحویل اتاق، پذیرش هویت شما را تأیید می‌کند و یک کارت می‌دهد که در اتاق و باشگاه را باز می‌کند، نه اتاق‌های دیگر و نه بخش‌های کارکنان، و در زمان تسویه از کار می‌افتد. کارت حاوی پاسپورت شما نیست. اگر گمش کنید، پذیرش آن را باطل می‌کند و یکی جدید می‌دهد.
- پذیرش همان سرور مجوز است (صفحه ورود Google).
- بررسی هویت شما ورود شما به Google است.
- کارت کلید همان توکن دسترسی است.
- «فقط اتاق و باشگاه» همان scopeهایی است که تأیید کرده‌اید.
- تسویه یعنی انقضای توکن یا لغو دسترسی توسط شما.
اپی که استفاده می‌کنید هرگز رمز Google شما را نمی‌بیند، فقط کارت کلید را می‌بیند.
OAuth گام به گام چطور کار می‌کند
رایج‌ترین جریان برای اپ‌های وب، جریان کد مجوز (authorization code flow) است. این اتفاق می‌افتد وقتی کاربری تقویم Google خود را به یک اپ زمان‌بندی وصل می‌کند:
- کلیک. کاربر روی «اتصال تقویم Google» کلیک می‌کند.
- هدایت به ارائه‌دهنده. اپ مرورگر را با client ID خودش، scopeهایی که می‌خواهد (خواندن رویدادهای تقویم) و redirect URI که Google باید کاربر را به آن برگرداند، به Google می‌فرستد.
- ورود و رضایت. کاربر اگر قبلاً وارد نشده، وارد Google می‌شود و صفحه رضایت را می‌بیند که فهرست آنچه اپ می‌خواهد را نشان می‌دهد. روی Allow کلیک می‌کند.
- بازگشت با یک کد. Google مرورگر را به redirect URI اپ برمی‌گرداند، همراه با یک authorization code کوتاه‌مدت و یک‌بارمصرف.
- تبادل روی سرور. سرور اپ آن کد را به‌همراه client secret مستقیماً به Google می‌فرستد و یک access token (و اغلب یک refresh token) دریافت می‌کند.
- استفاده از API. سرور با توکن دسترسی API تقویم Google را صدا می‌زند و رویدادهای کاربر را می‌گیرد.
callback در مرحله ۴ چیزی شبیه این است:
https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9
و پاسخ توکن در مرحله ۵ یک JSON مانند این است:
{
"access_token": "ya29.a0Af...",
"expires_in": 3599,
"refresh_token": "1//0gL...",
"scope": "https://www.googleapis.com/auth/calendar.readonly",
"token_type": "Bearer"
}
نکته مهم طراحی این است: تبادل توکن بین سرور و سرور انجام می‌شود، پس client secret و توکن‌ها هرگز لازم نیست از مرورگر عبور کنند.
OAuth در برابر OpenID Connect در برابر ورود اختصاصی شما
| به چه پرسشی پاسخ می‌دهد | مثال | |
|---|---|---|
| OAuth 2.0 | «این اپ به نمایندگی از کاربر مجاز است چه کاری انجام دهد؟» (مجوزدهی) | خواندن تقویم کاربر |
| OpenID Connect (OIDC) | «این کاربر کیست؟» (احراز هویت)، روی OAuth ساخته شده | «ورود با Google» که یک ایمیل تأییدشده برمی‌گرداند |
| ورود اختصاصی شما | «آیا این رمز درست حساب است؟» | ایمیل و رمز ذخیره‌شده (هش‌شده) در پایگاه داده شما |
بسیاری از اپ‌ها این‌ها را ترکیب می‌کنند: ورود با ایمیل و رمز، به‌علاوه «ورود با Google» از طریق OIDC، به‌علاوه اتصال‌های جدای OAuth به سرویس‌های دیگر.
اصطلاحات کلیدی
| اصطلاح | معنی |
|---|---|
| Provider / authorization server (ارائه‌دهنده / سرور مجوز) | سرویسی که کاربر در آن وارد می‌شود و دسترسی می‌دهد: Google، Microsoft، GitHub. |
| Client (کلاینت) | اپ شما، آن‌طور که نزد ارائه‌دهنده ثبت شده. |
| Client ID | شناسه عمومی اپ شما نزد ارائه‌دهنده. |
| Client secret | رمز خصوصی اپ شما نزد ارائه‌دهنده. فقط روی سرور. |
| Scope | یک مجوز مشخص، مثل «خواندن تقویم» یا «دیدن آدرس ایمیل». |
| Consent screen (صفحه رضایت) | صفحه‌ای که کاربر در آن scopeهای درخواستی را می‌بیند و تأیید می‌کند. |
| Redirect URI / callback URL | جایی که ارائه‌دهنده کاربر را به آن برمی‌گرداند. باید از قبل ثبت شود و دقیقاً مطابقت داشته باشد. |
| Access token (توکن دسترسی) | اعتبارنامه کوتاه‌مدت برای صدا زدن API. |
| Refresh token (توکن تازه‌سازی) | اعتبارنامه بلندمدت‌تر برای گرفتن توکن‌های دسترسی جدید. مثل رمز ذخیره‌اش کنید. |
| ID token | در OIDC، توکن امضاشده‌ای که توصیف می‌کند کاربر کیست. |
| PKCE | بررسی اضافی («کلید اثبات») که جلوی استفاده از کدهای ربوده‌شده را می‌گیرد. برای همه کلاینت‌ها توصیه می‌شود. |
| state | مقدار تصادفی که جریان را در برابر درخواست‌های جعلی محافظت می‌کند. |
تصورات غلط رایج
- «OAuth یک سیستم ورود است.» OAuth ساده فقط دسترسی می‌دهد؛ OpenID Connect هویت را مدیریت می‌کند. استفاده از یک توکن دسترسی خام به‌عنوان اثبات اینکه کسی کیست، باعث باگ‌های امنیتی واقعی شده است.
- «اپ رمز من را می‌گیرد.» هرگز نمی‌گیرد. موضوع همین است.
- «درخواست scopeهای بیشتر بی‌خطر است.» کاربران نسبت به درخواست‌های گسترده محتاط‌ترند، و ارائه‌دهنده‌هایی مثل Google ممکن است برای scopeهای حساس یا محدود بررسی اپ را لازم بدانند. فقط آنچه لازم دارید را بخواهید.
- «کلید کلاینت را می‌شود در فرانت‌اند گذاشت.» هر چیزی در کد مرورگر عمومی است. آن را در رمزهای سمت سرور نگه دارید.
- «در تست کار می‌کند، پس در محیط تولید هم کار می‌کند.» ارائه‌دهنده‌ها اغلب اپ‌های تأییدنشده را محدود می‌کنند، مثلاً به کاربران آزمایشی فهرست‌شده، و URL بازگشت برای دامنه زنده شما باید جداگانه ثبت شود.
- «توکن‌ها برای همیشه‌اند.» توکن‌های دسترسی سریع منقضی می‌شوند و کاربران می‌توانند دسترسی را لغو کنند. اپ شما باید هر دو را بی‌دردسر مدیریت کند.
از ابزار ساخت با هوش مصنوعی‌تان چه بخواهید
- «ورود با Google را با OpenID Connect و یک کتابخانه معتبر اضافه کن — جریان OAuth را دستی نساز.»
- «از جریان کد مجوز همراه PKCE استفاده کن و پارامتر
stateرا بررسی کن.» - «client ID و client secret را از متغیرهای محیطی روی سرور بخوان.»
- «فقط scopeهای لازم را درخواست کن: دسترسی فقط‌خواندنی به تقویم.»
- «همه URLهای بازگشتی را که باید در کنسول ارائه‌دهنده ثبت کنم فهرست کن، برای پیش‌نمایش، URL منتشرشده و دامنه اختصاصی‌ام.»
- «توکن‌های تازه‌سازی را در پایگاه داده رمزنگاری‌شده ذخیره کن، و توکن‌های منقضی یا لغوشده را با درخواست اتصال مجدد از کاربر مدیریت کن.»
- «به کاربران اجازه بده ادغام را از صفحه تنظیماتشان قطع کنند.»
OAuth و Mythex
Mythex برای کاربران نهایی اپ‌هایی که می‌سازید ورود داخلی ندارد؛ مستنداتش رویکرد «خودتان بیاورید» را توصیف می‌کند: یک کتابخانه احراز هویت یا سرویس میزبانی‌شده انتخاب می‌کنید، کلیدهایش را به‌عنوان رمزهای پروژه ذخیره می‌کنید و عامل کد را می‌نویسد. دستور افزودن احراز هویت یک پرامپت شروع برای این کار دارد. خود Mythex هم با OAuth سروکار دارد: می‌توانید با Google ثبت‌نام کنید، اتصال GitHub برای همگام‌سازی مخزن از OAuth گیت‌هاب استفاده می‌کند، و دستیارهای هوش مصنوعی که از طریق MCP به Mythex وصل می‌شوند از یک صفحه رضایت OAuth عبور می‌کنند. برای بیشتر، ببینید احراز هویت چیست و احراز هویت دو مرحله‌ای چیست.
پرسش‌ها
OAuth به زبان ساده چیست؟
OAuth یک روش استاندارد است که به کاربر اجازه می‌دهد یک اپ را به حساب خودش در سرویس دیگری وصل کند، مثلاً به یک اپ زمان‌بندی اجازه دهد تقویم Google او را بخواند، بدون اینکه رمز عبورش را به آن اپ بدهد. کاربر مجوزهای مشخصی را تأیید می‌کند و اپ یک توکن می‌گیرد که فقط برای همان‌ها قابل استفاده است.
آیا OAuth همان «ورود با Google» است؟
«ورود با Google» روی OAuth 2.0 به‌علاوه OpenID Connect ساخته شده است؛ لایه‌ای روی OAuth که روشی استاندارد برای شناساندن کاربر به اپ اضافه می‌کند. خود OAuth درباره دادن دسترسی است؛ OpenID Connect است که آن را به ورود تبدیل می‌کند.
توکن دسترسی OAuth چیست؟
توکن دسترسی یک اعتبارنامه است که اپ به API یک سرویس می‌فرستد تا ثابت کند دسترسی گرفته است. معمولاً کوتاه‌مدت است و به مجوزهایی (scopeها) که کاربر تأیید کرده محدود می‌شود. یک توکن تازه‌سازی (refresh token)، اگر صادر شده باشد، به اپ اجازه می‌دهد توکن‌های دسترسی جدید بگیرد بدون اینکه دوباره از کاربر بپرسد.
خطای redirect_uri_mismatch یعنی چه؟
یعنی URL بازگشت (callback) که اپ در هنگام ورود فرستاده دقیقاً با یکی که در کنسول توسعه‌دهنده ارائه‌دهنده ثبت شده مطابقت ندارد. URL دقیق را، شامل https، دامنه، مسیر و هر اسلش انتهایی، برای هر آدرسی که اپ روی آن اجرا می‌شود اضافه کنید.
آیا OAuth امن است؟
OAuth 2.0 به‌طور گسترده استفاده می‌شود و وقتی درست پیاده‌سازی شود امن است: با جریان کد مجوز همراه PKCE، URLهای بازگشت دقیق، پارامتر state، و نگه داشتن client secret و توکن‌ها روی سرور. بیشتر مشکلات از میان‌بر زدن در پیاده‌سازی است، و به همین دلیل استفاده از یک کتابخانه معتبر توصیه می‌شود.