احراز هویت و مجوز

حلقه AuthN/AuthZ قابل اعتماد یک نقطه از حقیقت در مورد شما (احراز هویت) و آنچه شما مجاز به انجام (مجوز) است. در یک پلت فرم با بسیاری از مارک ها، مناطق، ادغام و الزامات قانونی بالا، این کانتور باید مدولار، مشاهده و مدیریت شده توسط سیاستمداران، و نه «پراکندگی از if-s توسط خدمات».

1) شرایط و نقش های اساسی

شناسایی (ID): شناسایی (کاربر، سرویس، ارائه دهنده).
احراز هویت (AuthN): اثبات هویت (رمز عبور، MFA، گواهی).
مجوز (AuthZ) - سیاست و مبتنی بر متن می تواند/نمی تواند تصمیم بگیرد.
PDP/PEP: نقطه تصمیم گیری سیاست/نقطه اجرای سیاست.

ارائه دهنده هویت (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: پشتیبانی IdP خارجی (SAML/OIDC) برای B2B/اپراتورها.
• MFA: TOTP/WebAuthn/SMS (WebAuthn و TOTP توصیه می شود ؛ اس ام اس - برگشت).
• گام به گام مبتنی بر ریسک: برای اقدامات حساس (خروج وجوه، تغییر جزئیات) نیاز به MFA/pe-Auth دارد.

• تازه کردن چرخش نشانه + RT رجیستری با استفاده مجدد detectorized.
• Nonce/State + PKCE، CORS/CSRF سخت برای جریان مرورگر.
• نشانه های دسترسی کوتاه مدت (5-15 мин) + تازه کردن خاموش/RT.
• اتصال دستگاه (DPoP/mtls-bound tokens) برای عملیات بحرانی.

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)

mTLS بین خدمات + SPIFFE/SPIRE برای شناسایی حجم کار پایدار.

سرویس JWT با یک دوره کوتاه (≤5 دقیقه)، امضا شده توسط HSM/KMS ؛ حسابرسی صدور

دامنه مخاطبان: JWT فقط برای یک سرویس/دامنه خاص مناسب است.
مناطق اعتماد: خدمات از یک منطقه دیگر/مستاجر - PKI ها و سیاست های جداگانه.

5) مدل های مجوز: RBAC، ABAC، ReBAC

RBAC (نقش → مجوز): ساده و شفاف (مناسب برای پانل های مدیریت، اپراتورها).

ABAC (ویژگی های موضوع/منابع/زمینه): انعطاف پذیر برای "مستاجر =... و منطقه =... و kyc_tier≥2"

ReBAC (روابط): مفید برای دارایی های پیچیده («چه کسی صاحب یک نام تجاری/پوشه/کمپین»).

توصیه: ترکیبی - RBAC اساسی + زمینه شرایط ABAC + روابط ReBAC نقطه.

6) سیاست ها و اجرای (PDP/PEP)

PEP در دروازه و در خدمات: بازیابی زمینه (JWT، بلیط، IP/ASN، زمان، منطقه، لایه KYC)، درخواست PDP را تشکیل می دهد.

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" }
}

و توضیح «ALLOW/DENY» را برمی گرداند.

حافظه نهان راه حل PEP (TTL 30-120 c) باعث کاهش تأخیر می شود. معلولیت ناشی از رویدادهای «تغییر نقش/سیاست»

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) حوزه ها و قطعنامه ها

• منبع: action - 'wallet: read', 'wallet: transfer', 'bets: place', 'kyc: status. بخوانید.
• برای مدیران - 'admin:' در یک دامنه مستقل.
• برای ارائه دهندگان - "ارائه دهنده: گزارش. خوانده شده '،' ارائه دهنده: حوادث. فشار بده.

اصل حداقل امتیازات: ما فقط حوزه های لازم را اختصاص می دهیم ؛ «تشدید» (تمدید موقت حقوق) - با بلیط و با TTL.

8) چند مستاجر و مناطق (اقامت)

نشانه ها شامل «مستاجر»، «منطقه»، «مجوز» ؛ PDP مکاتبات را با منبع بررسی می کند.
نقش ها/سیاست ها - فضای نام برای هر مستاجر («نقش: brand _ eu/support»).
جداسازی کلیدهای امضا و لیست های لغو بر اساس منطقه ؛ درخواست های بین منطقه ای - فقط از طریق دروازه های قابل اعتماد.

9) جلسه و مدیریت دستگاه

فروشگاه جلسه سمت سرور برای وب (اتصال دستگاه/مرورگر، چرخش شناسه).
اتمام وقت بیکار/مطلق (به عنوان مثال 30 دقیقه/24 ساعت) ؛ اقدامات حساس - دوباره Auth/MFA.
فهرست دستگاههای فعال، «خروج از همه».
ناهنجاری ها: ورودی های همزمان از مناطق مختلف، افت مکرر MFA - سیگنال های خطر.

10) نمایندگی و رضایت (رضایت)

از طرف (OBO): این سرویس از طرف کاربر عمل می کند (یک پروکسی با یک «زیر »/« عمل» جداگانه).
رضایت: صفحه صریح برای دسترسی شریک به داده ها، ورود به سیستم رضایت با فراخوانی.
مجوزهای دسترسی موقت: حقوق برای N ساعت/روز به طور خودکار منقضی می شود.

11) کلید، امضا و چرخش

JWKS با «بچه»، چرخش خودکار، ذخیره سازی کلید های خصوصی در KMS/HSM.
الگوریتم ها: ES256/EdDSA برای JWT ؛ TLS 1. 2 +/mTLS.
دوره دو کلید: قبول هر دو «kids» قبل از ارتقاء مشتری کامل است.
RT و Token Introspection برای حوادث بحرانی یادآوری می کنند.

12) امنیت برنامه مشتری

SPA: کد مجوز + PKCE، بدون «ضمنی»، строгий CORS/محتوا-امنیت-سیاست.
موبایل: گواهی برنامه/بررسی دستگاه, ذخیره سازی امن RT, حفاظت ریشه/فرار از زندان.
دسکتاپ: مرورگر سیستم برای ورود (بدون وب جاسازی شده)، PKCE.

13) قراردادهای SDK مناسب

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" }

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) قابلیت مشاهده و حسابرسی

• 'athn _ success _ rate '/' mfa _ challenge _ rate '/' mfa _ fail _ rate'
• 'authz _ p95 _ ms', 'authz _ denied _ rate {reason}'
• 'invalid _ token _ rate', 'jwks _ skew _ ms', 'rt _ reuse _ detected'
• ناهنجاری های ورودی (دستگاه جدید، سرعت جغرافیایی)، دامنه های مشکوک.

• «چه کسی/چه چیزی/چه زمانی/کجا/چرا»، «تصمیم»، «سیاست _ نسخه»، «token _ kid»، «client _ id».
• صادرات برای انطباق (تنظیم کننده/فروشنده حسابرسی).

15) حفاظت از محیط و مشتری

دروازه PEP: محدودیت نرخ، ربات/امضا چک، حفاظت CSRF، CORS سخت، HSTS.
ترافیک داخلی: mTLS + سرویس JWT + شبکه های محدود.
Webhooks/collbacks خارجی: امضای بدن (HMAC/JWS)، پنجره های زمان، ضد پخش.

16) خطاهای معمول

نشانه های دسترسی طولانی مدت → نشت

جریان OAuth ضمنی در SPA.
بدون چرخش کلید و دوره کلید دوگانه.
نقش هاردکور به جای سیاست (غیر ممکن است به ممیزی/توضیح تصمیم گیری).
مخلوط کردن مستاجران/مناطق در یک «رول» یا «کلید».
بدون MFA در اقدامات حساس.
راه حل های AuthZ کش بدون تغییر نقش ناتوانی.

17) کتاب های بازی (کتاب های اجرا)

1. JWT سازش کلید امضا

لغو فوری «بچه»، انتشار JWKS جدید، ناتوانی اجباری RT/جلسات، گزارش حسابرسی.

2. Bulk 'invalid _ توکن

بررسی برای ناهماهنگی ساعت/طول عمر، ارتباط JWKS، سقوط کش.

3. ناهنجاری های ورودی

فعال کردن افزایش نمره خطر, نیاز به گام به بالا, اطلاع به کاربر, به طور موقت محدود کردن پرداخت.

4. خرابی در شناسۀ کاربر

سوئیچ به کش جلسه/نقش دستگاه، محدود کردن ورود به سیستم جدید، برگزاری جلسات فعال به TTL.

18) چک لیست پیش فروش

• OIDC/OAuth 2. 1 با PKCE، کوتاه AT، چرخش RT، اتصال دستگاه برای عملیات بحرانی.
• MFA (WebAuthn/TOTP) و گام به گام برای خروجی/تغییر جزئیات/نقش-تشدید.
• خدمات به خدمات: mTLS + SPIFFE، JWTs خدمات کوتاه مدت.
• سیاست های AuthZ (RBAC + ABAC/ReBAC) در PDP متمرکز ؛ PEP در دروازه و در خدمات.
• راه حل های ناتوانی کش; پیگیری حسابرسی غیر قابل تغییر است.
• چند مستاجر/مناطق: جداسازی کلید/سیاست/ورود به سیستم، حسابداری مجوز.
• JWKS/کلید در KMS/HSM، چرخش دو کلید، نظارت 'kid'.
• فیلترهای CSRF/CORS/HSTS/Rate-limit/bot در محیط.
• playbooks حادثه، لغو/چرخش/قفل دکمه های اجرا.
• مجموعه تست: واحد (سیاست ها)، قرارداد (SDK/جریان)، هرج و مرج (IdP، JWKS)، e2e (گام به گام، OBO، لغو).

19) قالب های پیکربندی کوتاه

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."]

نتیجه گیری

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