امنیت OAuth2 برای FAPI 2.0 و بانکداری اپن (OAuth2 Security for FAPI 2.0 and Open Banking)
تصور کنید یک بلیت کنسرت دارید: هرکس آن را در دست داشته باشد اجازه ورود دارد. مهم نیست چه کسی آن را خریده یا چطور به دست آورده است – اگر بتوانید بلیت را در ورودی نشان دهید، وارد میشوید. حتی میتوانید آن را به دوستتان بدهید تا او هم وارد شود.
این دقیقاً شبیه نحوه کار توکنهای Bearer در OAuth2 است. وقتی یک توکن صادر شد، هرکسی که آن را ارائه دهد میتواند به منابع محافظتشده دسترسی داشته باشد. این سادگی راحت است اما توکنهای Bearer را بسیار قابل سرقت و تکرار میکند. اگر یک مهاجم توکن را از طریق یک اپلیکیشن ناامن، شبکه در معرض خطر یا خطای لاگگیری رهگیری کند، میتواند تا زمان انقضای توکن، کلاینت را جعل هویت کند.
RFC 9449 راهی را تعریف میکند که توکنها بهجای اعتماد به دارنده، به یک کلید رمزنگاری متصل شوند.
به این روش نمایش اثبات مالکیت (DPoP) گفته میشود – و این یک جهش بزرگ در امنیت APIها، بهویژه در محیطهای باز، موبایل و مبتنی بر مرورگر است.
مزایای کلیدی DPoP شامل موارد زیر است:
-
جلوگیری از سرقت توکن: توکن دزدیدهشده بدون کلید خصوصی بیفایده است
-
مناسب برای SPAs و برنامههای موبایل: برخلاف mTLS، تماماً در لایه اپلیکیشن کار میکند
-
محافظت در برابر تکرار درخواست: شامل شناسه یکتا، روش و URL درخواست در هر اثبات
اگر این پیچیده به نظر میرسد، حق دارید – اما در ادامه همه چیز را قدمبهقدم بررسی میکنیم.
به مثال بلیت کنسرت بازگردیم: تاریخ و محل کنسرت روی آن نوشته شده، پس برای همه اجراها معتبر نیست. حال تصور کنید نام و تاریخ تولد شما هم روی بلیت چاپ شده باشد و مجبور باشید کارت شناسایی نشان دهید تا ثابت کنید بلیت متعلق به شماست.
در این مطلب، نحوه کار DPoP را توضیح میدهیم – هم ایدههای اصلی و هم نحوه استفاده در عمل. همچنین به کاربرد آن در صنایع مختلف و چگونگی پشتیبانی پلتفرمهای API مانند Tyk از اکوسیستمهای سازگار با FAPI 2.0 میپردازیم.
مشکل توکنهای Bearer
توکنهای Bearer استفاده سادهای دارند — هرکس توکن را داشته باشد میتواند به منبع مرتبط دسترسی یابد.
اما همین سادگی باعث ریسکهای امنیتی جدی میشود:
-
سرقت توکن: اگر توکن از طریق گزارشات برنامه، ذخیرهسازی مرورگر یا APIهای ناامن افشا شود، مهاجم میتواند کاربر را جعل کند.
-
حملات تکرار: توکنها میتوانند چندین بار استفاده شوند مگر اینکه بهطور صریح محدود و سریع منقضی شوند.
-
کلاینتهای فاقد امنیت ذخیرهسازی: کلاینتهای عمومی مانند مرورگرها و اپهای موبایل نمیتوانند اسرار را بهصورت امن ذخیره کنند، بنابراین توکنهای حامل در این محیطها بسیار آسیبپذیرند.
OAuth2 روش داخلی برای اطمینان از اینکه فقط کلاینت اصلی بتواند از توکن استفاده کند ندارد. هنگامی که صادر شد، هر کسی که توکن را داشته باشد میتواند از آن بهره ببرد. این ممکن است برای توکنهای کمارزش یا کوتاهمدت قابلقبول باشد. اما برای موارد حساس – مانند دادههای شخصی، شروع پرداخت، APIهای سلامت – یک مشکل جدی است.
ورود DPoP: اتصال توکن به کلاینت
DPoP توکن را به یک کلید رمزنگاری متصل میکند. در نتیجه، سیستم به دارنده کلید خصوصی اعتماد میکند، نه فقط ارائهدهنده توکن.
| ویژگی | توکن Bearer | توکن + اثبات DPoP |
|---|---|---|
| اتصال به کلاینت | خیر | بله |
| محافظت در برابر تکرار | خیر | بله |
| کار در موبایل/SPA | بله (ناامن) | بله |
| نیاز به mTLS | خیر | خیر |
DPoP امنیت مشابه mTLS را با سادگی Bearer ارائه میدهد.
اما mTLS چه؟
TLS متقابل استاندارد طلایی اصلی برای توکنهای محدود به ارسالکننده بود، جایی که هم کلاینت و هم سرور گواهیهای یکدیگر را تأیید میکنند. این روش بسیار امن است، اما از نظر عملیاتی سنگین است.
نیاز به صدور و مدیریت گواهیهای کلاینت دارد
برای کلاینتهای عمومی، اپهای موبایل و SPAها غیرممکن است، زیرا نمیتوانند اسرار را بهصورت امن ذخیره کنند
پیچیدگی زیرساختی زیادی ایجاد میکند مانند خاتمه در پراکسیهای لبه و مذاکره مجدد TLS
در مقابل، DPoP تضمینهای مشابهی را در لایه برنامه با استفاده از هدر درخواست فراهم میکند، بدون آن همه اصطکاک. این روش برای کلاینتهای عمومی و نیمهقابلاعتماد که نمیتوانند گواهیهای X.509 را ذخیره یا چرخش دهند، ایدهآل است.
FAPI 2.0 هر دو روش mTLS و DPoP را بهعنوان روشهای معتبر اتصال توکنها میپذیرد. DPoP اغلب برای کلاینتهای عمومی، SPAها و موبایل ترجیح داده میشود.
نحوه کار DPoP (گامبهگام)
در ادامه یک نمودار توالی سریع داریم که جریان DPoP را گامبهگام نشان میدهد.
کلاینت یک جفت کلید ایجاد میکند (نامتقارن، مانند EC P-256).
کلاینت یک اثبات اولیه DPoP ایجاد میکند و کلید عمومی را در هدر JWT قرار میدهد.
کلاینت با ارسال JWT در هدر DPoP درخواست توکن دسترسی میکند.
سرور احراز هویت یک توکن دسترسی متصل به DPoP صادر میکند که شامل اثر انگشت کلید در claim مربوط به cnf.jkt است.
برای هر درخواست API، کلاینت:
- یک اثبات جدید DPoP با jti، htm و htu یکتا تولید میکند.
- اثبات DPoP را همراه با Authorization: DPoP <token> ارسال میکند.
سرور منبع بررسی میکند:
- JWT مربوط به DPoP با کلید خصوصی صحیح امضا شده باشد.
- اتصال توکن به کلید با کلید موجود در JWT مطابقت داشته باشد.
- URL درخواست (htu) و روش (htm) با اثبات DPoP یکسان باشد.
- nonce (jti) بازپخش نشده باشد.
یک جریان واقعی DPoP
سناریو: کلاینت عمومی JavaScript (SPA یا موبایل) با Keycloak
-
مرحله ۱: ساخت کلید با WebCrypto
const keyPair = await crypto.subtle.generateKey(
{
name: "ECDSA",
namedCurve: "P-256"
},
true,
["sign", "verify"]
);-
مرحله ۲: ساخت JWT اثبات
{
"htu": "https://auth.example.com/token",
"htm": "POST",
"iat": 1680000000,
"jti": "unique-uuid"
}-
مرحله ۳: دریافت توکن با Authorization Code + PKCE
fetch("https://auth.example.com/token", {
method: "POST",
headers: {
"Content-Type": "application/x-www-form-urlencoded",
"DPoP": "<signed JWT>"
},
body: new URLSearchParams({
grant_type: "authorization_code",
code: "<auth_code>",
redirect_uri: "https://your-app/callback",
client_id: "your-client-id",
code_verifier: "<your-code-verifier>"
})
})-
مرحله ۴: ارسال درخواست API همراه اثبات
const dpopProof = await generateDPoPProof({
htu: "https://api.example.com/resource",
htm: "GET",
privateKey,
kid
});
fetch("https://api.example.com/resource", {
method: "GET",
headers: {
"Authorization": "Bearer <access_token>",
"DPoP": dpopProof
}
})چرا این برای پلتفرمهای API مهم است
DPoP فقط یک قابلیت اضافی نیست…
بانکداری و فینتک (Open Banking / PSD2)
DPoP و FAPI 2.0 بهویژه در بانکداری و فینتک اهمیت دارند، جایی که الزامات امنیتی قوی API وجود دارد. در PSD2 اتحادیه اروپا و بانکداری باز انگلستان، APIهای مربوط به حساب و دادههای پرداخت باید از پروفایلهای OAuth سطحمالی استفاده کنند.
FAPI 1.0 Advanced که در انگلستان و برزیل استفاده میشد، استفاده از mTLS را الزام کرده بود. FAPI 2.0 اکنون اجازه استفاده از DPoP را میدهد. این باعث میشود بانکها بتوانند بهتدریج از گواهیهای پیچیده فاصله بگیرند و از اتصال لایه برنامه سادهتر بهره ببرند.
این قابلیتها با الزامات قانونی مانند احراز هویت قوی مشتری و مدیریت رضایت همسو است.
بهداشت و درمان
-
دادههای سلامت بسیار حساس و تحت قوانین سختگیرانه مانند GDPR و HIPAA هستند.
-
APIهای مدرن سلامت (مانند SMART on FHIR) از OAuth2/OIDC استفاده میکنند.
-
DPoP تضمین بیشتری با اتصال توکنها به نمونه خاص برنامه فراهم میکند.
-
اگر توکن افشا شود، در جای دیگر قابل استفاده نیست.
دولت و خدمات عمومی
-
استانداردهای امنیتی سطح بالا در دولتها نیز در حال افزایش است.
-
FAPI در بسیاری از کشورها به یک استاندارد ملی تبدیل شده است.
-
DPoP اطمینان میدهد فقط اپلیکیشنهای تأییدشده میتوانند از توکنها استفاده کنند — موضوعی مهم در هویت دیجیتال شهروندان، خدمات اجتماعی و APIهای رأیگیری.
نتیجهگیری و گامهای بعدی
توکنهای Bearer ساده اما پرخطر هستند.
DPoP با اتصال توکن به کلید و تأیید مداوم مالکیت، امنیت را بدون پیچیدگی mTLS افزایش میدهد.
پیشنهاد میکنیم:
-
ارزیابی کنید آیا DPoP برای جریان OAuth شما مناسب است
-
اعتبارسنجی اثبات DPoP را در پلتفرم API خود فعال کنید
