एपीआई सुरक्षा और टोकन

संक्षिप्त सारांश

एपीआई सुरक्षा प्रमाणीकरण, प्राधिकरण, क्रिप्टोग्राफिक संरक्षण, विरोधी दुरुपयोग और अवलोकन तंत्र का एक संग्रह है जो यह सुनिश्चित करता है कि एक अनुरोध एक अपेक्षित संसाधन को एक अपेक्षित संसाधन पर निष्पादित करता है। मुख्य कलाकृति एक टोकन (या अनुरोध हस्ताक्षर) है जो कॉल करने का अधिकार साबित करता है। एक अच्छी वास्तुकला अल्पकालिक टोकन, स्पष्ट स्कोप, न्यूनतम विशेषाधिकार, रीप्ले सुरक्षा, दर सीमित और परिचालन प्रक्रियाओं (रोटेशन, ऑडिट, घटनाओं) पर निर्भर करती है।

एपीआई प्रमाणीकरण मॉडल - कब और क्या चुनें

एपीआई कुंजी (स्थिर रहस्य)

बी 2 बी एकीकरण और कम जोखिम वाले परिदृश्यों के लिए सरल। संदर्भ नहीं रखता है, सेवा पक्ष पर भंडारण की आवश्यकता है।

केवल IP/ASN अनुमति-सूची, निश्चित कोटा, छोटा TTL और घुमाव के साथ उपयोग करें।

OAuth 2। 1/OIDC

उपयोगकर्ता और साझेदार एकीकरण के लिए मानक: एक्सेस टोकन (अल्पकालिक) + रिफ्रेश टोकन (रोटेशन) + स्कोप।

सार्वजनिक ग्राहक - पीकेसीई के साथ; गोपनीय ग्राहक - ग्राहक गुप्त/एमटीएलएस के साथ।

क्लाइंट क्रेडेंशियल्स (m2m)

Mashina→mashina: कड़ाई से परिभाषित स्कोप और दर्शकों पर सेवाओं के लिए टोकन तक पहुंच, अक्सर रिफ्रेश के बिना (फिर से प्राप्त करें)।

एमटीएलएस (पारस्परिक टीएलएस)

पहचान को चैनल पर बांधता है। उच्च जोखिम या भुगतान एकीकरण (टीएलएस पर पीओपी) के लिए आदर्श।

OAuth के साथ जोड़ा जा सकता है (केवल mTLS क्लाइंट के लिए टोकन)।

हस्ताक्षर निवेदन करें (HMAC/EDDSA)

जब आपको परिवहन-स्वतंत्र PoP की आवश्यकता होती है: हस्ताक्षर हेडर, टाइमस्टैम्प और नॉन। वेबहुक और ऑफ़ लाइन सत्यापन के लिए सुविधाजनक।

टोकन प्रारूप और प्रकार

JWT (JWS, हस्ताक्षरित)

आत्मनिर्भर, स्थानीय स्तर पर जाँच; अनिवार्य 'is', 'उप', 'aud', 'exp', 'iat', 'jti', 'गुंजाइश'।

जोखिम - अधिक कठिन याद करें: घटनाओं में वापस बुलाए गए 'जेटी' की छोटी टीटीएल (5-15 मिनट) + सूची का उपयोग करें।

JWE (एन्क्रिप्टेड JWT)

आवश्यक है यदि पेलोड संवेदनशील है (पीआईआई)। लागत - उच्च जटिलता और ओवरहेड।

संदर्भ टोकन

अपारदर्शी पहचानकर्ता, प्राधिकरण सर्वर द्वारा आत्मनिरीक्षण के माध्यम से जाँच की गई - आसान याद/केंद्रीकरण।

PoP/DPoP

क्लाइंट कुंजी या टीएलएस सत्र के लिए एक टोकन बाइंडिंग चोरी टोकन के मूल्य को कम करता है।

टोकन सामग्री: न्यूनतम पर्याप्त

• 'is' (जारीकर्ता), 'उप' (विषय), 'aud' (लक्ष्य प्रणाली/संसाधन), 'exp' (शब्द), 'iat', 'nbf' (वैकल्पिक), 'jti'।
• 'स्कोप '/' अनुमतियाँ' (न्यूनतम आवश्यक), 'किरायेदार' (बहु-किरायेदार के लिए), 'डिवाइस _ अनुपालन '/' amr' (प्रमाणीकरण विधि), 'ip '/' asn' (यदि नीति पर लागू हो)।

• एक्सेस के लिए शॉर्ट टीटीएल (5-15 मिनट), रिफ्रेश - 12-48 एच (घूर्णन रोटेशन के साथ)।
• दर्शकों ('aud') एक कड़ाई से विशिष्ट संसाधन है, अन्यथा टोकन "पुन: प्रयोज्य" है।
• स्कोप - क्रिया और वस्तु (उदाहरण के लिए, 'भुगतान: वापस लेना। पढ़ें ')।
• हेडर और प्रॉक्सी के लिए आकार - ≤ 2-4 KB; अन्यथा गेटवे के साथ समस्या हो सकती है।

प्राधिकरण और नीतियाँ

RBAC + ABAC: भूमिका + संदर्भ (संगठन, भू, जोखिम, उपकरण की स्थिति)।

आवेदन से पहले एपीआई गेटवे/प्रॉक्सी (दूत/ओपीए) पर पीईपी/पीडीपी टोकन सत्यापन और निर्णय।

घोषणात्मक नियम: गिट में स्टोर करें, सीआई में नीति-परीक्षण पास करें।

rego package policy. withdraw

default allow = false

allow {
input. token. aud == "wallet-api"
input. token. scope[_] == "payments:withdraw. create"
input. device. compliant == true input. risk. score < 70
}

अनुरोध हस्ताक्षर (HMAC) और एंटी-रीप्ले

जब जरूरत होती है: वेबहूक, OAuth के बिना एकीकरण, महत्वपूर्ण संचालन की दोहरी जाँच।

X-Client-Id: <id>
X-Timestamp: 2025-11-05T13:20:10Z
X-Nonce: 4d1f...a2
X-Signature: base64(HMAC_SHA256(secret, method + "\n" + path + "\n" + sha256(body) + "\n" + timestamp + "\n" + nonce))

• समय मिसलिग्नमेंट> 300 s के साथ निवेदन अस्वीकारें।
• 5-15 मिनट के लिए नॉन स्टोर करें और रिप्ले (रीप्ले कैश) स्वीकार न करें।
• कैनोनाइज्ड क्वैरी दृश्य (विधि, पथ, क्वेरी, बॉडी हैश) पर हस्ताक्षर करें।

पहचान और लेन-देन संरक्षण

राइट-ऑफ/पे-आउट/संचालन बनाने के लिए पहचान-कुंजी: एक ही कुंजी - समान प्रभाव।

प्रमुख जीवनकाल ≥ बिजनेस टाइमआउट समय (आमतौर पर 24-72 घंटे) है।

सर्वर-साइड लॉजिक - इस कुंजी के लिए पहले से किए गए क्वैरी पैरामीटर की तुलना करें।

ब्राउज़र और मोबाइल ग्राहक

PKCE अनिवार्य है (सार्वजनिक ग्राहक)।

ब्राउज़र में टोकन ताज़ा करें - बचें; यदि आवश्यक हो - ROTATION + रीप्ले प्रतिक्रिया (रीप्ले-डिटेक्शन)।

भंडारण: सत्र भंडारण> स्थानीय भंडारण; बेहतर - फ्रंटेंड (BFF) के लिए बैकएंड टोकन के लिए जिम्मेदार है।

सेमसाइट, सुरक्षित, Httponly कुकी; CORS - स्पष्ट अनुमति-सूची, हेडर और तरीके; प्रीफ्लाइट कैशिंग सुरक्षित है।

एम 2 एम और उच्च जोखिम वाले एकीकरण

mTLS + OAuth2 स्कोप और 'aud' के साथ क्लाइंट क्रेडेंशियल्स।

प्रवेश द्वार पर IP/ASN अनुमति-सूची।

महत्वपूर्ण कार्यों के लिए TLS पर PoP/DPoP या HMAC हस्ताक्षर।

कोटा और दर प्रति संगठन/ग्राहक/कुंजी।

घूर्णन, याद और घटना प्रतिक्रिया

गुप्त और हस्ताक्षर कुंजी रोटेशन (JWKS): घटना पर अनुसूचित + लागू।

डुअल-की रोलआउट: अग्रिम (किड 2) में एक नई कुंजी जोड़ी प्रकाशित करें, इसके लिए टोकन पर हस्ताक्षर करें, टीटीएल समाप्त होने तक सत्यापन के लिए पुराने (किड 1) रखें।

रिफ्रेश-रोटेशन: हर रिफ्रेश एक्सचेंज - एक नया टोकन, पुराना तुरंत अमान्य हो जाता है; दोहराना - समझौता संकेत।

निरसन: जेडब्ल्यूटी के लिए - थोड़े समय के लिए याद किए गए 'जेटी' की सूची; संदर्भ टोकन के लिए - एएस पर तत्काल अवरोधन।

ब्रेक-ग्लास स्क्रिप्ट: न्यूनतम अधिकारों और हार्ड टीटीएल के साथ अस्थायी स्थिर क्रेडिट, लॉग में रिकॉर्ड।

दर सीमित, बॉट सुरक्षा और क्रूर बल संरक्षण

तीन-परत सीमा: प्रति-कुंजी/प्रति-आईपी/प्रति-संगठन।

बर्स्ट + निरंतर: टोकन-टैंक/स्लाइडिंग विंडो।

जटिल जाँच: डिवाइस फिंगरप्रिंट, व्यवहार संकेत, भू/एएसएन विसंगतियाँ, CAPTCHA केवल UI के लिए।

हस्ताक्षर/एनएमएसी और प्रमाणीकरण प्रयास विफल होने पर लॉकआउट/मंदी।

लॉगिंग, मेट्रिक्स और एसएलओ

लॉग का न्यूनतम सेट: 'अनुरोध _ id', 'क्लाइंट _ id', 'सब', 'aud', 'स्कोप', 'निर्णय', 'कारण', 'jti', 'ip', 'asn', 'कोटा _ state'।

• टोकन सत्यापन सफलता (%), p95 सत्यापन समय।
• रीप्ले विचलन की आवृत्ति, Idempotency-Key के डुप्लिकेट।
• PoP/DPoP/mTLS के साथ अनुरोधों का प्रतिशत।
• 'aud/scope' त्रुटियां, समाप्त 'exp', समय शिफ्ट (NTP)।

• औथ/एएस ≥ 99 उपलब्धता। 95 %/महीना; p95 आत्मनिरीक्षण ≤ 50 мс।
• टीटीएल <60 s के साथ शून्य टोकन (गार्ड मीट्रिक) में।
• 0 से कम। प्रति दिन 'aud/scope' त्रुटियों का 1% (एकीकरण की गुणवत्ता)।

कॉन्फ़िगरेशन उदाहरण

दूत: JWT और दर्शकों की जाँच

yaml http_filters:
- name: envoy. filters. http. jwt_authn typed_config:
providers:
as:
issuer: https://auth. example. com/
audiences: ["wallet-api"]
remote_jwks:
http_uri:
uri: https://auth. example. com/.well-known/jwks. json cluster: jwks_cluster cache_duration: 600s rules:
- match: { prefix: "/v1/withdraw" }
requires:
provider_and_audiences:
provider_name: as audiences: ["wallet-api"]

NGINX: mTLS к बैकएंड

nginx proxy_ssl_server_name on;
proxy_ssl_name wallet. internal;
proxy_ssl_certificate   /etc/nginx/mtls/client. crt;
proxy_ssl_certificate_key /etc/nginx/mtls/client. key;
proxy_ssl_trusted_certificate /etc/nginx/mtls/ca. crt;
proxy_ssl_verify on;
proxy_ssl_verify_depth 2;

हस्ताक्षर शीर्षक का उदाहरण (वेबहूक)

X-Signature: t=1730803210,n=ac12...,s=base64(HMAC_SHA256(secret, "POST\n/webhook\nsha256(body)\n1730803210\nac12..."))

सर्वर अस्वीकार करता है यदि 't' 300 c से अधिक पुराना है, 'n' पहले ही मिल चुका है, या 's' हरा नहीं करता है।

डेटा सुरक्षा और गोपनीयता

हॉलमार्क (विशेष रूप से पीआईआई) और जीवनकाल को कम करें।

तृतीय-पक्ष एकीकरण के लिए संवेदनशील टिकटों (JWE) को एन्क्रिप्ट करें।

लॉग में मास्क/डीएलपी: पैन/पीआईआई, टोकन के साथ लॉग बॉडी न करें - केवल 'बच्चा '/झंडे, न कि खुद रहस्य।

सामान्य त्रुटियाँ

लंबे समय तक रहने वाले एक्सेस टोकन और "अनन्त" रिफ्रेश।

'aud '/' स्कोप' की अनुपस्थिति - टोकन बहुउद्देशीय हैं।

'टाइमस्टैम्प '/' नॉन' के बिना वेबहुक का हस्ताक्षर।

केवल अनुप्रयोग में JWT की जाँच की जा रही है, गेटवे (PEP) पर नहीं।

कोई घुमाव और दोहरी कुंजी रोलआउट नहीं।

"CORS" और हेडर नियंत्रण के बिना असुरक्षित तरीकों की अनुमति दी।

BFF के बिना 'लोकसभा भंडारण' में टोकन का भंडारण।

कार्यान्वयन रोडमैप

1. एपीआई इन्वेंट्री और वर्गीकरण (सार्वजनिक/साझेदार/आंतरिक, संवेदनशीलता)।

2. AuthN मॉडल चयन: कस्टम के लिए, mTLS + क्लाइंट क्रेडेंशियल्स/HMAC m2m के लिए।

3. टोकन: महत्वपूर्ण संचालन के लिए छोटा टीटीएल, सख्त 'औड', स्कोप, डीपीओपी/पीओपी।

4. गेटवे पर PEP: JWT सत्यापन, हस्ताक्षर और दर ऐप की सीमा।

5. एंटी-रिप्ले और आइडेम्पोटेंसी: टाइमस्टैम्प/नॉन/आइडेम्पोटेंसी-की।

6. घुमाव और JWKS: दोहरी कुंजी, स्वचालन और सतर्कता।

7. अवलोकन: मैट्रिक्स/एसएलओ, एक्सेस लॉग, यूईबीए सिग्नल।

8. अभ्यास: हस्ताक्षर कुंजी, ताज़ा रिसाव, कोटा अधिभार।

IGaming/fintech के लिए विशिष्टता

भुगतान/भुगतान: mTLS + PoP/HMAC केवल, सख्त स्कोप ('वापस लेना। बनाएं '), पहचान की आवश्यकता है।

भागीदार (PSP/सामग्री प्रदाता): प्रति-भागीदार कुंजी/प्रमाणपत्र, IP/ASN अनुमति-सूची, व्यक्तिगत कोटा और डैशबोर्ड।

जीडीपीआर/पीसीआई डीएसएस: टिकटों को कम करना, तीसरे पक्ष के टोकन में पीआईआई को प्रतिबंधित करना, संवेदनशील संसाधनों तक पहुंच, नियमित पहुंच समीक्षा।

एंटी-दुरुपयोग: व्यवहार सीमा, भू-नियंत्रण, एपीआई स्तर पर बोनस दुरुपयोग के खिलाफ सुरक्षा।

FAQ

JWT या संदर्भ टोकन?

JWT - प्रदर्शन और स्वायत्तता; संदर्भ - केंद्रीकृत प्रतिक्रिया और घटना-प्रतिक्रिया की सादगी। अक्सर एक संकर: बाहरी - JWT, आंतरिक - संदर्भ।

क्या JWE की जरूरत है?

केवल तभी जब पेलोड में PII/सीक्रेट होते हैं। अन्यथा - न्यूनतम हॉलमार्क के साथ जेडब्ल्यूएस।

क्या मैं एपीआई चाबियों पर रह सकता हूं?

हां, लेकिन केवल एक छोटे टीटीएल, सख्त कोटा, आईपी-अनुमति-सूची और अनुरोध हस्ताक्षर के साथ। उपयोगकर्ताओं के लिए, OAuth/OIDC को पसंद किया जाता है।

DPoP/PoP अनिवार्य?

हमेशा नहीं। लेकिन उच्च जोखिम वाले संचालन (भुगतान, निष्कर्ष) के लिए अत्यधिक वांछनीय है।

कुल

विश्वसनीय एपीआई सुरक्षा अल्पकालिक टोकन, सटीक स्कोप और दर्शकों, सुरक्षित चैनलों (टीएलएस/एमटीएलएस) पर बनाई गई है, सीमा और अवलोकन द्वारा बढ़ाए गए हस्ताक्षर और सख्त एंटी-रीप्ले सुरक्षा का अनुरोध करते हैं। गेटवे पर स्वचालित घुमाव, दोहरी-कुंजी रोलआउट और राजनीतिक नियंत्रण जोड़ें - और आपका एपीआई उच्च प्रदर्शन और प्रबंधनीयता बनाए रखते हुए लीक, रिप्ले और दुरुपयोग के लिए प्रतिरोधी होगा।