کلید API چیست؟ راهنمای جامع احراز هویت، نحوه کارکرد و امنیت API Key

بخش زیادی از سرویس‌هایی که هر روز با آن‌ها کار می‌کنیم، برای تبادل اطلاعات به API متکی هستند. یک اپلیکیشن هواشناسی برای دریافت وضعیت آب‌وهوا، یک فروشگاه اینترنتی برای اتصال به درگاه پرداخت و حتی یک سامانه سازمانی برای ارتباط با سرویس‌های دیگر، همگی درخواست‌هایی را به APIهای مختلف ارسال می‌کنند. در چنین ارتباطی، سرویس مقصد باید بتواند درخواست‌ها را شناسایی و در صورت نیاز، دسترسی آن‌ها را کنترل کند.

یکی از روش‌های رایج برای این کار استفاده از کلید API یا API Key است. کلید API معمولا یک رشته منحصربه‌فرد از حروف، اعداد و گاهی کاراکترهای دیگر است که سرویس ارائه‌دهنده در اختیار یک برنامه، پروژه یا کاربر قرار می‌دهد. این کلید همراه درخواست ارسال می‌شود تا سرویس مقصد بتواند منبع درخواست را شناسایی کرده و سیاست‌های دسترسی، سهمیه و محدودیت‌های مربوط به آن را اعمال کند.

کلید API چیست و چه کاربردی دارد؟

کلید API در ساده‌ترین تعریف، یک شناسه محرمانه یا نیمه‌محرمانه برای شناسایی درخواست‌های ارسالی به یک API است. ساختار و کاربرد این کلید در سرویس‌های مختلف یکسان نیست؛ بعضی ارائه‌دهندگان از آن برای شناسایی پروژه استفاده می‌کنند و بعضی دیگر علاوه بر شناسایی، سطح دسترسی یا سهمیه مشخصی را نیز به هر کلید اختصاص می‌دهند.

برای مثال، فرض کنید یک سرویس پردازش تصویر API خود را در اختیار توسعه‌دهندگان قرار داده است. هنگام ایجاد یک پروژه، سرویس یک API Key در اختیار توسعه‌دهنده قرار می‌دهد. از آن به بعد، درخواست‌های مربوط به آن پروژه با این کلید قابل شناسایی هستند و سرویس می‌تواند تعداد درخواست‌ها، محدودیت مصرف یا دسترسی به قابلیت‌های مختلف را بر اساس همان کلید مدیریت کند.

بنابراین، API Key را نباید همیشه معادل «احراز هویت کاربر» در نظر گرفت. در بسیاری از APIها، کلید بیشتر برای شناسایی برنامه یا پروژه و اعمال سیاست‌های دسترسی استفاده می‌شود. اگر سرویس نیاز داشته باشد هویت یک کاربر مشخص را نیز مدیریت کند، معمولا از سازوکارهای دیگری مانند OAuth 2.0 و OpenID Connect استفاده می‌شود.

API Key چگونه کار می‌کند؟

استفاده از API Key از دید توسعه‌دهنده معمولا ساده است، اما پشت این درخواست ساده چند مرحله اتفاق می‌افتد. روند کلی را می‌توان این‌طور در نظر گرفت:

1. ایجاد کلید: توسعه‌دهنده در پنل سرویس یک پروژه ایجاد می‌کند و برای آن API Key می‌گیرد.
2. ارسال درخواست: برنامه هنگام فراخوانی API، کلید را طبق مستندات سرویس در هدر یا بخش مشخصی از درخواست قرار می‌دهد.
3. بررسی کلید: سرور مقدار دریافت‌شده را بررسی می‌کند و مشخص می‌کند کلید معتبر است یا منقضی، لغو یا مسدود شده است.
4. اعمال محدودیت‌ها: در صورت معتبر بودن کلید، سرویس می‌تواند سهمیه مصرف، Rate Limit، محدوده دسترسی و سایر قوانین مربوط به آن را بررسی کند.
5. پردازش درخواست: اگر درخواست شرایط لازم را داشته باشد، API عملیات مورد نظر را انجام داده و پاسخ را برمی‌گرداند.

برای نمونه، اگر یک سرویس برای هر API Key روزانه ۱۰۰۰ درخواست مجاز تعیین کرده باشد، پس از رسیدن به این سقف ممکن است درخواست‌های بعدی با خطای مربوط به محدودیت نرخ یا سهمیه پاسخ داده شوند.

البته کدهای وضعیت HTTP به سیاست همان API بستگی دارند. برای مثال، 401 Unauthorized معمولا زمانی استفاده می‌شود که اطلاعات احراز هویت یا اعتبارنامه ارائه‌شده معتبر نباشد و 403 Forbidden زمانی کاربرد دارد که درخواست شناسایی شده اما اجازه انجام عملیات مورد نظر را ندارد.

کلید API را چگونه در درخواست HTTP ارسال کنیم؟

روش ارسال API Key به طراحی API بستگی دارد، اما استفاده از هدر HTTP معمولا انتخاب مناسب‌تری نسبت به قرار دادن کلید در URL است. در بسیاری از سرویس‌ها، کلید با هدر اختصاصی مانند X-API-Key ارسال می‌شود.

برای مثال:

curl -X GET "https://api.example.com/v1/data"
-H "X-API-Key: YOUR_UNIQUE_API_KEY" 

برخی APIها از هدر Authorization استفاده می‌کنند:

curl -X GET "https://api.example.com/v1/data"
-H "Authorization: Api-Key YOUR_UNIQUE_API_KEY" 

فرمت دقیق هدر را باید از مستندات همان سرویس دریافت کرد. هیچ استاندارد واحدی وجود ندارد که همه APIها را ملزم به استفاده از یک نام یا قالب مشخص کند.

روش دیگر قرار دادن کلید در Query String است:

curl -X GET "https://api.example.com/v1/data?api_key=YOUR_UNIQUE_API_KEY" 

این روش در بعضی سرویس‌ها استفاده می‌شود، اما از نظر امنیتی معمولا انتخاب مطلوبی نیست. URL ممکن است در تاریخچه مرورگر، لاگ وب‌سرور، ابزارهای مانیتورینگ، پروکسی‌ها یا سرویس‌های تحلیل ترافیک ثبت شود. در نتیجه، قرار دادن یک کلید محرمانه در URL احتمال افشای تصادفی آن را بیشتر می‌کند.

البته استفاده از هدر به‌تنهایی امنیت API Key را تضمین نمی‌کند. اگر اتصال بدون HTTPS برقرار شود، کلید می‌تواند در مسیر انتقال افشا شود. همچنین ممکن است هدرها در بعضی زیرساخت‌ها لاگ شوند. بنابراین استفاده از HTTPS، مدیریت مناسب لاگ‌ها و محدود کردن دسترسی به کلید همچنان ضروری است.

تفاوت API Key با JWT و OAuth چیست؟

API Key، JWT و OAuth معمولا در بحث امنیت API کنار یکدیگر دیده می‌شوند، اما این سه اصطلاح به یک مفهوم اشاره نمی‌کنند.

API Key

API Key معمولا برای شناسایی یک برنامه، پروژه یا منبع درخواست و اعمال محدودیت‌هایی مانند سهمیه و Rate Limiting استفاده می‌شود. در برخی سرویس‌ها، کلید می‌تواند بخشی از کنترل دسترسی نیز باشد.

API Key معمولا اطلاعات محدودی درباره هویت درخواست‌کننده در اختیار سرویس قرار می‌دهد و به‌طور معمول برای مدیریت نشست کاربر یا دسترسی‌های پیچیده در سطح کاربر طراحی نشده است.

JWT

JWT یا JSON Web Token قالبی برای انتقال اطلاعات به‌شکل یک توکن امضاشده است. JWT می‌تواند شامل اطلاعاتی مانند شناسه کاربر، زمان انقضا و مجوزهای او باشد. سرور با بررسی امضای توکن می‌تواند از دستکاری نشدن محتوای آن مطمئن شود.

خود JWT یک روش احراز هویت یا مجوزدهی مستقل نیست؛ این قالب می‌تواند در یک سیستم احراز هویت یا مجوزدهی مورد استفاده قرار بگیرد.

OAuth 2.0

OAuth 2.0 یک چارچوب استاندارد برای واگذاری دسترسی به منابع است. برای مثال، یک برنامه می‌تواند با اجازه کاربر به بخشی از اطلاعات حساب او در یک سرویس دیگر دسترسی پیدا کند، بدون اینکه لازم باشد رمز عبور کاربر را در اختیار داشته باشد.

اگر هدف، ورود کاربر با حساب یک سرویس مانند Google باشد، معمولا OpenID Connect در کنار OAuth 2.0 مطرح می‌شود. OpenID Connect لایه‌ای برای احراز هویت است، در حالی که OAuth 2.0 اساسا برای واگذاری دسترسی طراحی شده است.

در نتیجه، نمی‌توان گفت API Key، JWT و OAuth رقیب مستقیم یکدیگر هستند. هرکدام مسئله متفاوتی را حل می‌کنند و حتی ممکن است در یک معماری، هم‌زمان از چند مورد آن‌ها استفاده شود.

مزایای استفاده از API Key برای ارائه‌دهندگان سرویس

API Key برای سرویس‌دهنده فقط یک ابزار شناسایی نیست. وقتی هر پروژه یا مشتری با کلید مشخصی به API متصل می‌شود، مدیریت مصرف و دسترسی نیز ساده‌تر خواهد شد.

پایش و تفکیک مصرف

سرویس‌دهنده می‌تواند درخواست‌های مربوط به کلیدهای مختلف را از یکدیگر تفکیک کند. این اطلاعات برای بررسی میزان مصرف، شناسایی الگوهای غیرعادی و پیدا کردن بخش‌هایی از API که بیشترین استفاده را دارند، کاربرد دارد.

اعمال Rate Limiting

می‌توان برای هر کلید محدودیت مشخصی در نظر گرفت؛ مثلا حداکثر ۱۰۰ درخواست در دقیقه. این محدودیت از مصرف بی‌رویه منابع جلوگیری می‌کند و در صورت ارسال تعداد زیادی درخواست مخرب یا غیرعادی، شدت فشار روی سرویس را کاهش می‌دهد.

مدیریت هزینه و سهمیه

در APIهای تجاری، میزان مصرف هر پروژه می‌تواند مبنای محاسبه هزینه قرار بگیرد. برای مثال، یک سرویس پردازش متن ممکن است بر اساس تعداد درخواست‌ها یا حجم داده پردازش‌شده هزینه دریافت کند.

لغو یا تعویض دسترسی

اگر کلیدی افشا شود یا رفتار غیرعادی از آن مشاهده شود، سرویس‌دهنده می‌تواند همان کلید را لغو یا محدود کند، بدون اینکه لازم باشد دسترسی سایر مشتریان را تغییر دهد.

خطرات امنیتی API Key

API Key در بسیاری از سرویس‌ها مانند یک اعتبارنامه دسترسی عمل می‌کند. اگر مهاجم به کلیدی دسترسی پیدا کند که مجوزهای گسترده یا اعتبار مالی دارد، می‌تواند از آن برای ارسال درخواست، مصرف سهمیه یا حتی ایجاد هزینه برای صاحب حساب استفاده کند.

یکی از نمونه‌های رایج، قرار گرفتن کلید در یک مخزن عمومی Git است. مهاجم می‌تواند مخزن را پیدا کند، کلید را استخراج کند و در فاصله کوتاهی از آن استفاده کند. به همین دلیل، نحوه نگهداری کلید به اندازه نحوه استفاده از آن اهمیت دارد.

کلید را در کد سمت کاربر قرار ندهید

قرار دادن API Key محرمانه در JavaScript، اپلیکیشن موبایل یا هر کدی که به دست کاربر نهایی می‌رسد، روش امنی نیست. حتی اگر کلید در کد فشرده یا مبهم شده باشد، کاربر کنترل کاملی روی محیط اجرای برنامه دارد و در بسیاری از موارد می‌تواند آن را استخراج کند.

اگر API Key باید محرمانه باقی بماند، درخواست را از طریق بک‌اند ارسال کنید. در این معماری، کلید روی سرور نگهداری می‌شود و کاربر نهایی مستقیما به آن دسترسی ندارد.

از متغیرهای محیطی استفاده کنید

کلیدهای محرمانه نباید مستقیما در کد منبع نوشته شوند. یکی از روش‌های رایج، نگهداری آن‌ها در متغیرهای محیطی است. برای پروژه‌های محلی ممکن است این اطلاعات در فایل .env قرار بگیرند و این فایل نیز در .gitignore قرار داده شود.

برای مثال:

export API_KEY="YOUR_UNIQUE_API_KEY"

سپس برنامه مقدار متغیر API_KEY را از محیط اجرا دریافت می‌کند.

استفاده از متغیر محیطی به این معنا نیست که کلید به‌طور خودکار امن شده است. سطح دسترسی سرور، سیستم استقرار، لاگ‌ها و ابزارهای مدیریت اسرار نیز باید به‌درستی تنظیم شوند.

کلید را وارد مخزن عمومی نکنید

فایل‌های حاوی اطلاعات محرمانه نباید در مخازن عمومی قرار بگیرند. استفاده از .gitignore می‌تواند از اضافه شدن تصادفی برخی فایل‌ها به commitهای بعدی جلوگیری کند، اما اگر کلید قبلا در تاریخچه Git ثبت شده باشد، حذف فایل کافی نیست.

در چنین شرایطی باید کلید افشاشده را فورا لغو یا تعویض کرد. پاک کردن آن از فایل یا commit فعلی، به‌تنهایی باعث بی‌اعتبار شدن کلید نمی‌شود.

دسترسی کلید را محدود کنید

اگر ارائه‌دهنده API امکان اعمال محدودیت دارد، کلید را با کمترین سطح دسترسی مورد نیاز ایجاد کنید. بعضی سرویس‌ها امکان محدود کردن کلید بر اساس IP، دامنه، APIهای قابل استفاده یا نوع عملیات را فراهم می‌کنند.

این محدودیت‌ها باعث می‌شوند در صورت افشای کلید، دامنه سوءاستفاده احتمالی کمتر شود. البته نوع محدودیت‌های قابل استفاده به معماری و امکانات همان سرویس بستگی دارد.

کلیدها را دوره‌ای تعویض کنید

Key Rotation یا چرخش کلید به معنای جایگزین کردن اعتبارنامه‌های قدیمی با کلیدهای جدید است. این کار به‌ویژه برای کلیدهایی که مدت زیادی مورد استفاده قرار گرفته‌اند یا در معرض افشا بوده‌اند، اهمیت دارد.

در سیستم‌های بزرگ بهتر است تعویض کلید به شکلی انجام شود که کلید جدید ابتدا فعال شود و پس از انتقال کامل سرویس، کلید قدیمی لغو شود. این روش از ایجاد قطعی هنگام تغییر اعتبارنامه جلوگیری می‌کند.

آیا API Key برای امنیت API کافی است؟

پاسخ به این سوال به نوع سرویس و سطح دسترسی مورد نیاز بستگی دارد. برای یک API ساده که فقط باید پروژه‌ها را شناسایی کند و برای هرکدام سهمیه مشخصی در نظر بگیرد، API Key می‌تواند انتخاب مناسبی باشد.

اما اگر API قرار است اطلاعات خصوصی کاربران را مدیریت کند یا دسترسی‌های مختلفی را در سطح کاربر کنترل کند، معمولا به سازوکارهای کامل‌تری نیاز است. در چنین شرایطی ممکن است OAuth 2.0، OpenID Connect، توکن‌های کوتاه‌عمر، کنترل دسترسی مبتنی بر نقش و سایر روش‌های امنیتی در کنار هم استفاده شوند.

نکته مهم این است که API Key را نباید به‌عنوان جایگزین همه روش‌های احراز هویت و مجوزدهی در نظر گرفت. این کلید فقط یکی از ابزارهایی است که می‌تواند در معماری امنیتی یک API به کار گرفته شود.

بهترین روش برای نگهداری API Key چیست؟

برای محافظت از API Key می‌توان چند اصل ساده اما مهم را رعایت کرد:

• کلیدهای محرمانه را در کد سمت کاربر قرار ندهید.
• برای ارتباط با API همیشه از HTTPS استفاده کنید.
• کلید را در URL قرار ندهید، مگر اینکه API چنین روشی را الزامی کرده باشد.
• کلیدهای محرمانه را در مخازن عمومی Git قرار ندهید.
• دسترسی هر کلید را تا حد ممکن محدود کنید.
• برای کلیدها تاریخ انقضا یا فرایند چرخش در نظر بگیرید.
• لاگ‌های سرور و ابزارهای مانیتورینگ را بررسی کنید تا کلید به‌صورت ناخواسته ثبت نشود.
• در صورت افشای کلید، به حذف آن از کد اکتفا نکنید و خود کلید را لغو یا تعویض کنید.
• برای سرویس‌های حساس، مدیریت اسرار را به ابزارهای تخصصی بسپارید.

جمع‌بندی

API Key یکی از ساده‌ترین روش‌ها برای شناسایی درخواست‌های ارسال‌شده به یک API و مدیریت دسترسی آن‌هاست. سرویس‌دهنده می‌تواند با استفاده از این کلیدها مصرف هر پروژه را جداگانه بررسی کند، محدودیت درخواست اعمال کند و در صورت مشاهده سوءاستفاده، دسترسی همان کلید را لغو کند.

با این حال، API Key را نباید معادل احراز هویت کامل کاربر دانست. در معماری‌هایی که به مدیریت هویت کاربران یا دسترسی‌های پیچیده نیاز دارند، روش‌هایی مانند OAuth 2.0 و OpenID Connect کاربرد بیشتری دارند و ممکن است در کنار API Key استفاده شوند.

از طرف دیگر، هر API Key که نقش اعتبارنامه داشته باشد باید مانند یک اطلاعات محرمانه با آن رفتار شود. نگهداری کلید در سمت سرور، استفاده از HTTPS، محدود کردن سطح دسترسی، جلوگیری از ثبت آن در مخازن عمومی و تعویض کلیدهای افشاشده، بخش مهمی از امنیت یک API را تشکیل می‌دهند.