API - Authentication types: Basic, Bearer, API Keys, OAuth 2.0 (Access Token, Refresh Token)

Authentication چیست؟

Authentication یعنی فرایند احراز هویت؛ یعنی سیستم بررسی می‌کند درخواست واقعاً از چه کاربر، سیستم یا کلاینتی آمده است.
در تست API، Authentication مشخص می‌کند آیا درخواست اجازه ورود به API را دارد یا نه. این احراز هویت معمولاً از طریق Header، Token، API Key یا مکانیزم‌های استاندارد مثل OAuth 2.0 انجام می‌شود.

نکته مهم:
Authentication با Authorization فرق دارد.

• Authentication = «تو کی هستی؟»

• Authorization = «با این هویت، به چه چیزی دسترسی داری؟»

مثلاً اگر کاربر با Token معتبر وارد شود، بخش Authentication موفق شده؛ اما اینکه اجازه ویرایش حساب مشتری دیگر را داشته باشد یا نه، مربوط به Authorization است.

چرا این سرفصل مهم است؟

چون در تست API، فقط بررسی Body و Status Code کافی نیست. خیلی از Failureهای مهم در سیستم‌های بانکی و Backend اصلاً از جنس امنیت، توکن، سطح دسترسی، انقضای نشست یا ضعف در احراز هویت هستند.
تستر باید بتواند تشخیص دهد:

• درخواست بدون احراز هویت باید چه خطایی بدهد

• توکن منقضی چه رفتاری باید داشته باشد

• API Key یا Bearer Token کجا ارسال می‌شود

• فرق 401 و 403 چیست

• Access Token و Refresh Token چه نقشی دارند

Basic Authentication

Basic Auth چیست؟

در Basic Authentication، کلاینت username و password را در Header Authorization می‌فرستد. ساختار کلی آن به شکل زیر است:

Authorization: Basic <base64(username:password)>

یعنی مقدار username:password به Base64 تبدیل می‌شود و در Header قرار می‌گیرد.

مثال:

Authorization: Basic YWxpOjEyMzQ1Ng==

ویژگی مهم Basic Auth

Basic Auth ساده است، اما از نظر امنیتی ضعیف‌تر از مدل‌های توکنی است، چون credential اصلی کاربر در هر درخواست ارسال می‌شود.
خود Base64 هم Encryption نیست؛ فقط Encoding است. بنابراین Basic Auth فقط وقتی قابل قبول است که ارتباط حتماً روی HTTPS باشد.

کاربرد Basic Auth

معمولاً در این سناریوها دیده می‌شود:

• سرویس‌های ساده یا قدیمی

• محیط‌های داخلی

• بعضی APIهای مدیریتی

• بعضی تست‌های اولیه یا سرویس‌های legacy

از دید تستر چه چیزهایی مهم است؟

در تست Basic Auth باید این سناریوها را بررسی کنی:

• username/password معتبر → درخواست موفق

• password اشتباه → 401 Unauthorized

• username اشتباه → 401

• نبودن Header Authorization → 401

• خراب بودن فرمت Basic → خطای مناسب

• بررسی اینکه API فقط روی HTTPS استفاده شود

Bearer Token

Bearer Token چیست؟

در این مدل، کلاینت به‌جای username/password در هر درخواست، یک Token می‌فرستد. این Token معمولاً در Header Authorization قرار می‌گیرد:

Authorization: Bearer <token>

مثال:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI...

مفهوم Bearer

Bearer یعنی هر کسی که این Token را در اختیار داشته باشد، می‌تواند از آن برای دسترسی استفاده کند. بنابراین Bearer Token باید مثل credential حساس در نظر گرفته شود.

Bearer Token از کجا می‌آید؟

معمولاً Bearer Token از یکی از این مسیرها به دست می‌آید:

• Endpoint لاگین

• سرویس احراز هویت

• OAuth 2.0 Authorization Server

بعد از دریافت Token، کلاینت آن را در درخواست‌های بعدی در Header می‌فرستد.

کاربرد Bearer Token

در APIهای مدرن، Bearer Token یکی از رایج‌ترین روش‌های احراز هویت است، مخصوصاً وقتی:

• سیستم Sessionless باشد

• API مبتنی بر JWT یا token-based auth باشد

• چند سرویس با هم کار کنند

• اپ موبایل یا فرانت‌اند با بک‌اند صحبت کند

از دید تستر چه چیزهایی مهم است؟

در تست Bearer Token باید این موارد بررسی شوند:

• token معتبر → درخواست موفق

• token حذف شود → 401 Unauthorized

• token اشتباه یا دستکاری‌شده باشد → 401

• token منقضی باشد → 401

• token کاربر بدون مجوز روی resource ممنوع → 403 Forbidden

• token revoke شده دیگر نباید معتبر باشد

API Key

API Key چیست؟

API Key یک کلید شناسایی برای Client یا Consumer است که همراه درخواست ارسال می‌شود تا API بداند درخواست از کدام اپلیکیشن یا مصرف‌کننده آمده است.
API Key معمولاً در یکی از این محل‌ها قرار می‌گیرد:

• Header

• Query Parameter

• گاهی Body

مثال در Header:

x-api-key: 123456789abcdef

مثال در Query:

GET /customers?api_key=123456789abcdef

API Key چه نقشی دارد؟

API Key بیشتر برای شناسایی Client/App، کنترل مصرف، Rate Limiting و Quota Management استفاده می‌شود.
در بعضی سیستم‌ها API Key نقش Authentication هم دارد، اما از نظر معماری معمولاً Bearer/OAuth بالغ‌تر و امن‌تر هستند.

نکته امنیتی مهم

اگر API Key در Query String ارسال شود، احتمال ثبت شدن آن در Logs، Proxy، Browser History یا Monitoring Tools بیشتر است. برای همین، ارسال آن در Header معمولاً امن‌تر است.

از دید تستر چه چیزهایی مهم است؟

در تست API Key باید این موارد را بررسی کنی:

• key معتبر → درخواست موفق

• key حذف شود → خطای مناسب

• key اشتباه/منقضی/غیرفعال → 401 یا 403

• اگر key فقط در Header مجاز است، ارسال در Query باید مطابق Contract بررسی شود

• نشت API Key در URL یا logها از نظر امنیتی ریسک مهمی است

OAuth 2.0

OAuth 2.0 چیست؟

OAuth 2.0 یک Authorization Framework استاندارد برای صدور و مدیریت Token است.
در عمل، OAuth 2.0 کمک می‌کند Client بدون ارسال مستقیم username/password در هر درخواست، از طریق Access Token به API دسترسی بگیرد.

به زبان ساده:

1. Client از Authorization Server توکن می‌گیرد

2. API اصلی یا Resource Server آن Token را بررسی می‌کند

3. اگر Token معتبر باشد، دسترسی می‌دهد

اجزای مهم در OAuth 2.0

معمولاً این نقش‌ها را داریم:

• Resource Owner: صاحب داده، معمولاً کاربر

• Client: اپلیکیشن یا سیستمی که درخواست می‌زند

• Authorization Server: سروری که Token صادر می‌کند

• Resource Server: API اصلی که داده را نگه می‌دارد و Token را اعتبارسنجی می‌کند

Access Token

Access Token چیست؟

Access Token توکنی است که برای دسترسی به API استفاده می‌شود. این توکن معمولاً کوتاه‌عمر است و در Header به شکل Bearer ارسال می‌شود:

Authorization: Bearer <access_token>

نقش Access Token

• دسترسی به Resourceهای API

• حمل اطلاعاتی مثل هویت کاربر، زمان انقضا، scope یا claimها

• جایگزین ارسال مستقیم username/password در هر درخواست

رفتار معمول Access Token

• بعد از Login یا OAuth Flow صادر می‌شود

• در هر Request محافظت‌شده استفاده می‌شود

• وقتی منقضی شد، دیگر نباید برای API قابل قبول باشد

از دید تستر چه چیزهایی مهم است؟

در تست Access Token باید این موارد بررسی شوند:

• access token معتبر → درخواست موفق

• access token منقضی → 401 Unauthorized

• access token دستکاری‌شده → 401

• access token بدون scope لازم → 403 Forbidden

• access token کاربر A روی داده‌ی کاربر B → باید مطابق Authorization کنترل شود

Refresh Token

Refresh Token چیست؟

Refresh Token برای گرفتن Access Token جدید استفاده می‌شود، وقتی Access Token منقضی شده باشد.
یعنی کاربر یا Client مجبور نیست دوباره از اول login کند؛ به‌جای آن با Refresh Token از Authorization Server یک Access Token جدید می‌گیرد.

نقش Refresh Token

• تمدید نشست بدون ورود مجدد

• کاهش نیاز به نگه‌داشتن Access Token بلندمدت

• افزایش امنیت با کوتاه‌عمر نگه داشتن Access Token

تفاوت Access Token و Refresh Token

Access Token

• برای صدا زدن API

• کوتاه‌عمر

• در Header Bearer استفاده می‌شود

Refresh Token

• برای گرفتن Access Token جدید

• معمولاً بلندعمرتر

• معمولاً فقط به Authorization Server ارسال می‌شود، نه به همه‌ی APIها

از دید تستر چه چیزهایی مهم است؟

در تست Refresh Token باید این سناریوها بررسی شوند:

• refresh token معتبر → access token جدید صادر شود

• refresh token اشتباه یا منقضی → خطای مناسب

• refresh token revoke شده → نباید کار کند

• refresh token متعلق به client یا user دیگر → نباید قابل استفاده باشد

• اگر سیستم rotation دارد، بعد از استفاده از refresh token قبلی، reuse آن نباید مجاز باشد

تفاوت Bearer Token و OAuth 2.0

این نکته خیلی مهم است:

Bearer Token

فقط روش ارسال Token در Request است:

Authorization: Bearer <token>

OAuth 2.0

مکانیزم یا Framework صدور و مدیریت Token است.
یعنی معمولاً OAuth 2.0 توکن صادر می‌کند و آن Token بعداً به شکل Bearer Token در API استفاده می‌شود.

پس:

• OAuth 2.0 = سازوکار گرفتن/تمدید/مدیریت Token

• Bearer Token = روش استفاده از Token در درخواست

Status Codeهای مهم در Authentication

401 Unauthorized

وقتی احراز هویت انجام نشده یا Token/Credential معتبر نیست. مثال:

• Token ارسال نشده

• Password اشتباه است

• Access Token منقضی شده

• API Key نامعتبر است

403 Forbidden

وقتی کاربر احراز هویت شده، ولی اجازه دسترسی به Resource یا عملیات موردنظر را ندارد. مثال:

• Token معتبر است ولی scope لازم ندارد

• کاربر معمولی می‌خواهد عملیات Admin انجام دهد

• کاربر به داده‌ی مشتری دیگر دسترسی ندارد

مقایسه کوتاه مدل‌ها

Basic Auth

ارسال مستقیم username/password در Header Authorization. ساده است، ولی ضعیف‌تر و وابسته به HTTPS.

Bearer Token

ارسال Token در Header Authorization. رایج در APIهای مدرن و Sessionless.

API Key

کلید شناسایی Client/App برای دسترسی یا کنترل مصرف API. معمولاً در Header یا Query ارسال می‌شود.

OAuth 2.0

چارچوب استاندارد صدور و مدیریت Access Token و Refresh Token برای دسترسی امن‌تر و حرفه‌ای‌تر به API.

اهمیت این سرفصل برای Backend Tester

Backend Tester باید بتواند:

• نوع احراز هویت API را از Swagger، Headers یا Contract تشخیص دهد

• Headerهای امنیتی مثل Authorization یا x-api-key را درست ست کند

• تفاوت 401 و 403 را بداند

• سناریوهای منفی مثل missing token، expired token، invalid API key و refresh failure را تست کند

• بفهمد مشکل از Authentication است یا Authorization

• در تحلیل Defect تشخیص دهد Failure از Token validation، Session management، Scope/Role یا Refresh flow آمده است

نکته امتحانی مهم

در پاسخ امتحانی فقط ننویس:

Authentication یعنی احراز هویت و انواعش Basic و Bearer و OAuth است.

این پاسخ ضعیف است. پاسخ خوب باید این کلیدواژه‌ها را داشته باشد:
Authorization Header, Basic, Bearer, API Key, OAuth 2.0, Access Token, Refresh Token, 401 Unauthorized, 403 Forbidden, Token Expiry, Token Validation, Authentication vs Authorization

نمونه پاسخ کامل کوتاه

در APIها، Authentication مکانیزمی برای احراز هویت Client یا کاربر است و مشخص می‌کند چه کسی درخواست را ارسال کرده است. روش‌های رایج آن شامل Basic Authentication با ارسال username/password در Header Authorization، Bearer Token با ارسال Token در Header، API Key برای شناسایی Client و OAuth 2.0 برای صدور و مدیریت Access Token و Refresh Token است. Access Token برای دسترسی به API استفاده می‌شود و Refresh Token برای دریافت Access Token جدید بعد از انقضا به کار می‌رود. در تست API باید سناریوهایی مثل missing token, invalid credential, expired token, invalid API key و تفاوت 401 و 403 بررسی شوند.

کلیدواژه‌ها

Authentication Authorization Basic Auth Bearer Token API Key OAuth 2.0 Access Token Refresh Token Authorization Header Token Validation Token Expiry 401 Unauthorized 403 Forbidden Credential Sessionless Authentication Authorization Server Resource Server Client Resource Owner Scope Token Rotation Revoked Token

Authentication (فرایند احراز هویت کاربر یا کلاینت): برای تشخیص هویت درخواست‌کننده در API استفاده می‌شود.

Authorization (کنترل سطح دسترسی پس از احراز هویت): مشخص می‌کند کاربر یا کلاینت بعد از احراز هویت به چه Resource یا عملیاتی دسترسی دارد.

Basic Auth (روش احراز هویت با ارسال username و password در Header Authorization): در سرویس‌های ساده یا قدیمی دیده می‌شود و نیازمند HTTPS است.

Bearer Token (توکنی که در Header Authorization برای دسترسی به API ارسال می‌شود): رایج‌ترین مدل احراز هویت توکنی در APIهای مدرن است.

API Key (کلید شناسایی Client یا Consumer): برای شناسایی اپلیکیشن، کنترل مصرف، rate limiting و گاهی Authentication استفاده می‌شود.

OAuth 2.0 (چارچوب استاندارد صدور و مدیریت Token): برای دسترسی امن و کنترل‌شده به APIها با استفاده از Access Token و Refresh Token استفاده می‌شود.

Access Token (توکن کوتاه‌عمر برای دسترسی به API): در Header به‌صورت Bearer ارسال می‌شود و برای فراخوانی endpointهای محافظت‌شده کاربرد دارد.

Refresh Token (توکن مورد استفاده برای گرفتن Access Token جدید): در زمان انقضای Access Token برای تمدید نشست بدون login مجدد استفاده می‌شود.

Authorization Header (هدر حاوی اطلاعات احراز هویت مثل Basic یا Bearer): محل اصلی ارسال credential یا token در بسیاری از APIهاست.

Token Validation (اعتبارسنجی Token در سمت سرور): برای بررسی صحت، انقضا، امضا، scope و مجوزهای Token استفاده می‌شود.

Token Expiry (انقضای Token پس از مدت مشخص): برای محدود کردن عمر توکن و افزایش امنیت استفاده می‌شود.

401 Unauthorized (خطای احراز هویت ناموفق): وقتی credential یا token وجود ندارد یا معتبر نیست استفاده می‌شود.

403 Forbidden (خطای عدم مجوز): وقتی کاربر احراز هویت شده ولی اجازه دسترسی به Resource یا عملیات را ندارد استفاده می‌شود.

Credential (اطلاعات احراز هویت مثل username/password یا token): برای اثبات هویت درخواست‌کننده استفاده می‌شود.

Sessionless Authentication (احراز هویت بدون نگهداری session سمت سرور): معمولاً با Bearer Token یا JWT در APIهای مدرن دیده می‌شود.

Authorization Server (سروری که Token صادر می‌کند): در OAuth 2.0 مسئول صدور Access Token و Refresh Token است.

Resource Server (سروری که API و Resource را ارائه می‌دهد): Token را اعتبارسنجی می‌کند و در صورت مجاز بودن پاسخ می‌دهد.

Client (اپلیکیشن یا سیستمی که درخواست API ارسال می‌کند): در OAuth و سایر مدل‌های Authentication مصرف‌کننده سرویس است.

Resource Owner (مالک داده یا کاربر نهایی): در OAuth 2.0 معمولاً همان کاربر است که دسترسی به Resource از طرف او صادر می‌شود.

Scope (محدوده دسترسی Token): مشخص می‌کند Token برای چه عملیات یا Resourceهایی معتبر است.

Token Rotation (تعویض Token، به‌ویژه Refresh Token، بعد از استفاده): برای افزایش امنیت و جلوگیری از سوءاستفاده از Tokenهای سرقت‌شده کاربرد دارد.

Revoked Token (توکنی که باطل شده و دیگر نباید پذیرفته شود): در Logout، امنیت یا مدیریت نشست اهمیت دارد.