Logo GH

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

विश्वसनीय AuthN/AuthZ लूप सत्य का एक बिन्दु है कि आप कौन हैं (सत्यापन) और आपको क्या करने की अनुमति है (प्राधिकरण)। कई ब्रांडों, क्षेत्रों, एकीकरणों और उच्च नियामक आवश्यकताओं के साथ एक मंच में, यह समोच्च राजनेताओं द्वारा मॉड्यूलर, मनाया और प्रबंधित किया जाना चाहिए, न कि "सेवाओं द्वारा अगर-एस का प्रकीर्णन।"

1) बुनियादी शर्तें और भूमिकाएँ

पहचान (आईडी): पहचान (उपयोगकर्ता, सेवा, प्रदाता)।

प्रमाणीकरण (AuthN): पहचान का प्रमाण (पासवर्ड, MFA, प्रमाणपत्र)।

प्राधिकरण (AuthZ) -Policy और संदर्भ-आधारित कैन/तय नहीं कर सकता.

पीडीपी/पीईपी: नीति निर्णय बिंदु/नीति प्रवर्तन बिंदु।

IdP: पहचान प्रदाता (OIDC)।

विषय/संसाधन/कार्रवाई/संदर्भ: कौन/क्या/क्या करता है/किन परिस्थितियों में।

2) कुल मिलाकर लूप आर्किटेक्चर


[ IdP (OIDC) ]
│ OIDC/OAuth 2. 1 (PKCE, JAR/JARM)

[ Token Service / JWKS / KMS ]
│klyuchi (rotate)
│ JWT/Access/Refresh, mTLS

[API Gateway (PEP)] Solution/Policy ──kesh
│ authN/CSRF/CORS/rate-limit

[ Microservices (PEP)]──PDP (OPA/cedar) ──Policy Store (GitOps)
│audit/metriki

[ Data/Providers ]── service-to-service (mTLS+JWT/Spiffe)

सिद्धांत: टोकन और नीति निर्माण, स्थानीय अनुप्रयोग का केंद्रीकरण; "न्यूनतम विशेषाधिकार" और स्पष्ट प्रतिनिधिमंडल।

3) उपयोगकर्ता प्रमाणीकरण (OIDC/OAuth 2। 1)

पैटर्न:
  • प्राधिकरण कोड + PKCE (हमेशा SPA/मोबाइल के लिए)।
  • SSO: b2b/ऑपरेटरों के लिए बाहरी IdP समर्थन (SAML/OIDC)।
  • MFA: TOTP/WebAuthn/SMS (WebAuthn और TOTP की सिफारिश की गई; एसएमएस - फॉलबैक)।
  • जोखिम-आधारित चरण-अप: संवेदनशील कार्यों के लिए (धन की वापसी, विवरण परिवर्तन) के लिए एमएफए/पे-ऑथ की आवश्यकता होती है।
सुरक्षा प्रथाएं:
  • टोकन रोटेशन + आरटी रजिस्ट्री को पुन: उपयोग पता लगाने के साथ ताज़ा करें।
  • Nonce/State + PKCE, ब्राउज़र धाराओं के लिए सख्त CORS/CSRF।
  • अल्पकालिक पहुंच टोकन (5-15 мин) + मूक ताज़ा/आरटी।
  • महत्वपूर्ण कार्यों के लिए उपकरण बाइंडिंग (डीपीओपी/एमटीएलएस-बाउंड टोकन)।
JWT (उपयोगकर्ता) का उदाहरण:
json
{
"iss": "https://auth. example. com",
"sub": "user_9f12",
"aud": ["wallet","catalog"],
"exp": 1730385600,
"iat": 1730384700,
"tenant": "brand_eu",
"region": "EE",
"amr": ["pwd, ""webauthn"] ,//authentication methods
"scp": ["wallet:read","bets:place","kyc:status. read"],
"sid": "sess_a1b2c3",      // session id
"acr": "urn: mfa: strong "//warranty level
}

4) सेवा-सेवा प्रमाणीकरण (mTLS, SPIFFE, JWT)

स्थिर कार्यभार पहचानकर्ताओं के लिए सेवाओं + SPIFFE/SPIRE के बीच mTLS।

एचएसएम/केएमएस द्वारा हस्ताक्षरित छोटी अवधि (≤5 मिनट) के साथ सेवा JWT; जारी करने का लेखा परीक्षा।

ऑडियंस-स्कोपेड: JWT केवल एक विशिष्ट सेवा/डोमेन के लिए उपयुक्त है।

विश्वास क्षेत्र: किसी अन्य क्षेत्र/किरायेदार से सेवाएं - अलग पीकेआई और नीतियां।

5) प्राधिकरण मॉडल: RBAC, ABAC, ReBAC

RBAC (भूमिकाएँ → अनुमतियाँ): सरल और पारदर्शी (व्यवस्थापक पैनल, ऑपरेटरों के लिए उपयुक्त)।

ABAC (विषय/संसाधन/संदर्भ विशेषताएं): "किरायेदार =... के लिए लचीला और क्षेत्र =... और kyc_tier≥2"

ReBAC (रिश्ते): जटिल होल्डिंग्स के लिए उपयोगी ("जो एक ब्रांड/फ़ोल्डर/अभियान का मालिक है")।

सिफारिश: हाइब्रिड - बुनियादी RBAC + संदर्भ ABAC शर्तें + बिंदु ReBAC संबंध।

6) नीतियां और प्रवर्तन (पीडीपी/पीईपी)

गेटवे पर और सेवाओं में PEP: संदर्भ (JWT, टिकट, IP/ASN, समय, क्षेत्र, KYC परत) को पुनः प्राप्त करता है, PDP के लिए एक अनुरोध बनाता है।

पीडीपी (जैसे) OPA/देवदार) प्राप्त करता है:
json
{
"subject": { "sub":"user_9f12", "roles":["support"], "kyc":2, "tenant":"brand_eu" },
"action": "bets. place",
"resource": { "game_id":"g_42", "provider":"pr_x" },
"context": { "region":"EE", "ip_asn":"AS12345", "time":"2025-10-31T12:34:56Z" }
}

और रिटर्न 'EMELE/DENY' + स्पष्टीकरण।

पीईपी का समाधान कैश (टीटीएल 30-120 सी) विलंबता को कम करता है; "भूमिका/नीति परिवर्तन" घटनाओं द्वारा विकलांगता

उदाहरण नीति (छद्म रेगो):
rego package bets

default allow = false

allow {
input. action == "bets. place"
input. subject. kyc >= 2 input. subject. tenant == input. context. tenant not blocked_region within_limits
}

blocked_region { input. context. region == "NL" }
within_limits { input. context. bet_amount <= data. limits. max_bet[input. subject. tenant] }

7) स्कोप और संकल्प

नामकरण:
  • संसाधन: क्रिया - 'बटुआ: पढ़ें', 'बटुआ: हस्तांतरण', 'दांव: स्थान', 'kyc: स्थिति। पढ़ें '।
  • प्रशासन के लिए - 'व्यवस्थापक:' एक स्टैंडअलोन डोमेन में।
  • प्रदाताओं के लिए - 'प्रदाता: रिपोर्ट। पढ़ें ',' प्रदाता: घटनाएँ। पुश '।

न्यूनतम विशेषाधिकारों का सिद्धांत: हम केवल आवश्यक स्कोप प्रदान करते हैं; "एस्केलेशन" (अधिकारों के अस्थायी विस्तार) - टिकट द्वारा और टीटीएल के साथ।

8) बहु-किरायेदार और क्षेत्र (निवास)

टोकन में 'किरायेदार', 'क्षेत्र', 'लाइसेंस' शामिल हैं; पीडीपी संसाधन के साथ पत्राचार की जांच करता है।

भूमिकाएँ/नीतियाँ - प्रति किरायेदार ('भूमिका: ब्रांड _ ईयू/समर्थन')।

क्षेत्र द्वारा हस्ताक्षर कुंजियों और निरसन सूचियों का पृथक्करण; क्रॉस-रीजनल अनुरोध - केवल विश्वसनीय गेटवे के माध्यम से।

9) सत्र और उपकरण प्रबंधन

वेब के लिए सर्वर-साइड सत्र स्टोर (उपकरण/ब्राउज़र बाइंडिंग, पहचानकर्ता रोटेशन).

आइडल/एब्सोल्यूट टाइमआउट (जैसे। 30 मिनट/24 एच); संवेदनशील कार्रवाई - पुन: आत्मा/एमएफए।

सक्रिय उपकरणों की सूची, "सभी से बाहर निकलें"।

विसंगतियां: विभिन्न क्षेत्रों से एक साथ इनपुट, अक्सर एमएफए डिप्स - जोखिम संकेत।

10) प्रतिनिधिमंडल और सहमति (सहमति)

ऑन-फॉर-ऑफ (OBO): सेवा उपयोगकर्ता की ओर से कार्य करती है (एक अलग 'उप '/' अधिनियम' के साथ एक प्रॉक्सी टोकन)।

सहमति: डेटा तक साझेदार पहुंच के लिए स्पष्ट स्क्रीन, रिकॉल के साथ सहमति का लॉग।

अस्थायी पहुंच-जनादेश: एन घंटे/दिनों के अधिकार स्वचालित रूप से समाप्त हो जाते

11) कुंजी, हस्ताक्षर और रोटेशन

KMS/HSM में 'किड', स्वचालित रोटेशन, निजी कुंजियों का भंडारण के साथ JWKS।

एल्गोरिदम: JWT के लिए; टीएलएस 1। 2 +/mTLS।

दोहरी कुंजी अवधि: क्लाइंट अपग्रेड पूरा होने से पहले दोनों 'किड्स' स्वीकारें।

आरटी और टोकन आत्मनिरीक्षण महत्वपूर्ण घटनाओं के लिए याद करते हैं।

12) ग्राहक आवेदन सुरक्षा

SPA: प्राधिकरण कोड + PKCE, कोई 'अंतर्निहित', строгий CORS/सामग्री-सुरक्षा-नीति।

मोबाइल: ऐप अटेस्टेशन/डिवाइस चेक, सुरक्षित आरटी स्टोरेज, रूट/जेलब्रेक सुरक्षा।

डेस्कटॉप: लॉगिन के लिए तंत्र ब्राउज़र (कोई एम्बेडेड वेब-दृश्य नहीं), पीकेसीई.

13) सुविधाजनक एसडीके अनुबंध

मूल्यांकन (AuthZ) API:
http
POST /authz/evaluate
Authorization: Bearer <access_jwt>
Body: { "action":"bets. place", "resource":{"game_id":"g_42"}, "context":{"bet_amount":5. 0} }
→ 200 { "decision":"ALLOW", "ttlMs":60000, "explain":"kyc>=2, limit ok" }
टोकन एक्सचेंज (OBO):
http
POST /oauth/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=<user_jwt>&actor_token=<service_jwt>&audience=wallet

14) अवलोकन और लेखा परीक्षा

मेट्रिक्स:
  • 'authn _ sumper _ rate '/' mfa _ challenge _ rate '/' mfa _ fail _ rate'
  • 'authz _ p95 _ ms', 'authz _ dened _ rate {count}'
  • 'invalid _ token _ rate', 'jwks _ skew _ ms', 'rt _ reuse _ detected'
  • इनपुट की विसंगतियाँ (नया उपकरण, भू-वेग), संदिग्ध स्कोप।
लॉग/लेखा परीक्षा (अपरिवर्तनीय):
  • 'जो/क्या/कब/कहां/क्यों', 'निर्णय', 'नीति _ संस्करण', 'टोकन _ किड', 'क्लाइंट _ आईडी'।
  • अनुपालन के लिए निर्यात (नियामक/विक्रेता-लेखा परीक्षा)।

15) परिधि और ग्राहक सुरक्षा

गेटवे PEP: दर-सीमा, बॉट/सिग्नेचर चेक, CSRF सुरक्षा, सख्त CORS, HSTS।

आंतरिक यातायात: mTLS + सेवा JWT + सीमित नेटवर्क।

वेबहुक/बाहरी कोलबैक: बॉडी सिग्नेचर (HMAC/JWS), टाइम विंडो, एंटी-रीप्ले।

16) विशिष्ट त्रुटियाँ

लंबे समय तक पहुंच टोकन - लीक।

एसपीए में निहित OAuth प्रवाह।

कोई कुंजी घुमाव और दोहरी कुंजी अवधि नहीं.

नीतियों के बजाय कट्टर भूमिकाएं (निर्णयों की लेखापरीक्षा/व्याख्या करना असंभव है)।

किरायेदारों/क्षेत्रों को एक 'रोल' या 'की' में मिलाना।

संवेदनशील कार्यों पर कोई कदम एमएफए नहीं।

भूमिका परिवर्तन विकलांगता के बिना AuthZ समाधान कैश।

17) प्लेबुक (रनबुक)

1. JWT हस्ताक्षर कुंजी समझौता

तत्काल 'बच्चा', नए JWKS के प्रकाशन, आरटी/सत्र विकलांगता, ऑडिट रिपोर्ट को मजबूर किया।

2. थोक 'invalid _ token'

घड़ी मिसलिग्नमेंट/जीवनकाल, JWKS प्रासंगिकता, कैश क्रैश के लिए जाँच करें।

3. इनपुट विसंगतियाँ

बढ़े हुए जोखिम स्कोरिंग को सक्षम करें, स्टेप-अप की आवश्यकता होती है, उपयोगकर्ता को सूचित करें, अस्थायी रूप से भुगतान को

4. आईडीपी असफल

सत्र कैश/रोल-डिवाइस पर स्विच करें, नए लॉगिन को सीमित करें, सक्रिय सत्रों को टीटीएल पर रखें.

18) प्री-सेल चेकलिस्ट

  • OIDC/OAuth 2। PKCE के साथ 1, शॉर्ट एटी, आरटी रोटेशन, क्रिटिकल ऑपरेशन के लिए डिवाइस बाइंडिंग।
  • एमएफए (वेबऑटन/टीओटीपी) और आउटपुट/विवरण/भूमिका-वृद्धि के परिवर्तन के लिए कदम-अप।
  • सेवा-से-सेवा: mTLS + SPIFFE, अल्पकालिक सेवा JWTs।
  • केंद्रीकृत पीडीपी में AuthZ नीतियां (RBAC + ABAC/ReBAC); प्रवेश द्वार पर और सेवाओं में पीईपी।
  • विकलांगता समाधान कैश; ऑडिट ट्रेल अपरिवर्तनीय।
  • मल्टी-किरायेदार/क्षेत्र: कुंजी/नीति/लॉग अलगाव, लाइसेंस लेखांकन।
  • KMS/HSM में JWKS/कुंजी, दोहरी कुंजी रोटेशन, 'किड' की निगरानी।
  • परिधि पर CSRF/CORS/HSTS/दर-सीमा/बॉट फिल्टर।
  • हादसा प्लेबुक, revoke/घूमने/लॉकडाउन रन बटन।
  • टेस्ट सूट: यूनिट (नीतियां), अनुबंध (एसडीके/प्रवाह), अराजकता (आईडीपी, जेडब्ल्यूकेएस), ई 2 ई (स्टेप-अप, ओबीओ, रिवोक)।

19) मिनी कॉन्फ़िगरेशन टेम्पलेट्स

स्कोप रजिस्ट्री (YAML):
yaml scopes:
wallet: read: {desc: "Reading balance"}
wallet: transfer: {desc: "Transfer of funds," sensitive: true, step_up: true}
bets: place: {desc: "Bet"}
kyc:status. read: {desc: "KYC status"}
roles:
support:
allow: [wallet:read, kyc:status. read]
finance:
allow: [wallet:read, wallet:transfer]
player:
allow: [bets:place]
पीडीपी नीति (क्षेत्र की स्थिति):
yaml deny:
- when: { region: ["NL","BE"] }
actions: ["bets."]

निष्कर्ष

प्रमाणीकरण और प्राधिकरण लूप एक पुस्तकालय नहीं है, बल्कि एक मंच की क्षमता है: अल्पकालिक टोकन और प्रबंधित कुंजी, केंद्रीकृत नीतियां और उनके स्थानीय अनुप्रयोग, मल्टीफैक्टर और चरण-अप, किरायेदारों/क्षेप का सख्त अलगाव। यह डिजाइन परिवर्तनों को सुरक्षित बनाता है, नियामक को समझाने योग्य है और उत्पाद के लिए पारदर्शी है - और बाजार और कमांड द्वारा स्केलिंग एक नियमित संचालन बन जाता है, न कि एक उपलब्धि।

Contact

हमसे संपर्क करें

किसी भी प्रश्न या सहायता के लिए हमसे संपर्क करें।हम हमेशा मदद के लिए तैयार हैं!

Telegram
@Gamble_GC
इंटीग्रेशन शुरू करें

Email — अनिवार्य है। Telegram या WhatsApp — वैकल्पिक हैं।

आपका नाम वैकल्पिक
Email वैकल्पिक
विषय वैकल्पिक
संदेश वैकल्पिक
Telegram वैकल्पिक
@
अगर आप Telegram डालते हैं — तो हम Email के साथ-साथ वहीं भी जवाब देंगे।
WhatsApp वैकल्पिक
फॉर्मैट: देश कोड और नंबर (उदा. +91XXXXXXXXXX)।

बटन दबाकर आप अपने डेटा की प्रोसेसिंग के लिए सहमति देते हैं।