احراز هویت در API؛ کلید، توکن و OAuth به زبان ساده و با مثال

تفاوت کلید API، توکن و OAuth چیست و هر کدام کجا استفاده میشود؟ راهنمای سادهٔ احراز هویت API با نکات امنیتی عملی برای پروژههای واقعی.
چرا APIها قفل میشوند؟
هر سرویس آنلاینی که داده میدهد یا میگیرد، باید بداند «سمت خط کیست». بدون این شناسایی، هر کسی میتوانست به نام دیگران داده بخواند، هزینه ایجاد کند یا سرویس را با درخواستهای بیشمار زمین بزند. احراز هویت (Authentication) جایی است که سرویس میفهمد طرف چه کسی است و مجوزدهی (Authorization) تعیین میکند این طرف اجازهٔ چه کارهایی را دارد. این دو مفهوم را با هم اشتباه نگیرید؛ اول هویت، بعد دسترسی.
برای درک کل تصویر، بهتر است اول مبانی REST API را مرور کنید. APIها سه وضعیت رایج دارند: عمومی بدون احراز هویت (مثل سرویسهای آبوهوا)، سرویس با کلید (رایگان اما محدود به مثلاً ۱۰۰ درخواست در روز) و سرویس با ورود کاربر (دادهٔ شخصی مثل ایمیلها یا کیف پول). هر وضعیت ابزار خودش را دارد و همینجاست که کلید، توکن و OAuth وارد میشوند.
کلید API؛ سادهترین شکل احراز هویت
کلید API (API Key) رشتهای طولانی و تصادفی است که مثل رمز عبورِ برنامهٔ شما عمل میکند؛ معمولاً در هدر درخواست یا بهصورت پارامتر در آدرس فرستاده میشود. وقتی در پنل یک سرویس دکمهٔ Get API Key را میزنید، دقیقاً همین رشته را میگیرید و از آن به بعد، هر درخواستی که این کلید را داشته باشد، به حساب شما ثبت میشود. کلید به سرویس میگوید «این درخواست از کدام برنامه آمده» اما نمیگوید «چه کاربری پشت آن است».
قاعدهٔ امنیتی اول و مهم: کلید را هرگز مستقیم در کد ننویسید و هرگز در گیتهاب پوشش ندهید. کلیدها در فایل .env زندگی میکنند و نام این فایل باید در .gitignore باشد؛ عادتی که در آموزش گیت و گیتهاب از صفر بهخوبی توضیح داده شده است. اگر کلیدی لو رفت، همان لحظه از پنل سرویس آن را باطل (Revoke) کنید و کلید تازه بگیرید؛ کلید لو رفته، مثل کلید خانهای است که به همه داده شده.
توکنها و JWT؛ شناسنامهٔ امضاشده
برای دادههای شخصی، کلید ثابت کافی نیست؛ کاربر باید «وارد شود» تا سرویس بداند دادهٔ چه کسی درخواست شده است. اینجا توکن وارد میشود: بعد از لاگین، سرور رشتهای امضاشده برمیگرداند و برنامهٔ شما در هر درخواست بعدی، همان را در هدر Authorization میگذارد:
fetch('/api/me', { headers: { Authorization: 'Bearer ' + token } });
معروفترین قالب توکن JWT است: سه بخش که با نقطه از هم جدا میشوند؛ سرآیند (الگوریتم امضا)، بدنه (شناسهٔ کاربر و تاریخ انقضا) و امضا. دو نکتهٔ عملی مهم وجود دارد: اول، هر توکن تاریخ انقضا دارد (معمولاً از ۱۵ دقیقه تا چند ساعت) و بعد از آن باید با «Refresh Token» توکن تازه گرفت؛ دوم، توکن را هم مثل کلید محرمانه نگه دارید، چون توکن دزدیدهشده یعنی دسترسی دزدیدهشده. بدنهٔ JWT را هر کسی میتواند بخواند، پس در آن رمز یا دادهٔ حساس نگذارید؛ چیزی که جعل را ناممکن میکند فقط امضاست.
OAuth در یک پاراگراف قابلفهم
OAuth راهحل این سؤال است: «چطور به یک برنامهٔ ثالث اجازه بدهم بدون دیدن رمز من، به دادههایم دسترسی داشته باشد؟». وقتی با «ورود با گوگل» وارد سایتی میشوید، همین OAuth در حال کار است: سایتِ آنسو شما را به گوگل میبرد، شما آنجا اجازه میدهید و گوگل فقط یک توکنِ محدود برمیگرداند، نه رمز شما. بهعنوان مبتدی لازم نیست OAuth را از صفر پیاده کنید؛ کتابخانههای آماده این چرخه را کامل مدیریت میکنند و کار شما فقط چسباندن «دکمهٔ ورود با گوگل» و خواندن توکن است. چیزی که باید بماند: کلید برای برنامه است، توکن برای کاربر و OAuth برای اجازهدادنِ امن به دیگران.
امنیت عملی: پنج قانون نگهداری کلید و توکن
- فقط متغیر محیطی: کلیدها در فایل
.envزندگی میکنند، نه در کد؛ و این فایل هرگز commit نمیشود. - کلید مخفی فقط در سرور: کلیدهای محرمانه را از مرورگر نفرستید؛ بگذارید بکاند شما آنها را نگه دارد و مرورگر فقط با سرور خودتان حرف بزند.
- هر سرویس، کلید جدا: یک کلید برای همهجا یعنی یک نشت، همهجا در خطر؛ جدا کردن کلیدها، انفجار را کوچک نگه میدارد.
- چرخش منظم: هر چند ماه کلیدها را عوض کنید و کلیدهای بیاستفاده را از پنل حذف کنید.
- تفکیک خطاها: کد وضعیت ۴۰۱ یعنی شناسه نامعتبر است و ۴۰۳ یعنی شناسه درست است اما اجازه ندارید؛ خواندن درست این دو، نصف دیباگ است.
تمرین عملی با APIهای رایگان
راه جاافتادن این مفاهیم، استفادهٔ واقعی است نه خواندن. یک سرویس رایگان با کلید ساده انتخاب کنید (مثلاً سرویس آبوهوا) و اولین درخواست را با کلید بزنید تا خطای ۴۰۱ و ۲۰۰ را با چشم خودتان ببینید. بعد یک سرویس با لاگین کاربر را امتحان کنید تا چرخهٔ توکن و انقضایش را لمس کنید. فهرست APIهای رایگان عمومی گزینههای آماده برای این تمرین دارد و برای فهم بخشهای مبهم مستندات سرویسها هم روش خواندن مستندات فنی کمک زیادی میکند. وقتی اولین احراز هویت موفق را ساختید، این مفاهیم دیگر هرگز برایتان مبهم نمیمانند.
این مطلب برایتان مفید بود؟
با پسندیدن، به ما کمک میکنید مطالب بهتری منتشر کنیم.



