身份验证和授权

AuthN/AuthZ的可靠路径是一个真实点，说明您是谁（身份验证）以及您允许什么（授权）。在具有多个品牌，区域，集成和高监管要求的平台中，此轮廓必须是模块化的，可观察的和政策驱动的，而不是"按服务划分的if砂浆"。

1）基本术语和角色

身份识别（ID）：身份识别（user, service, provider）。
身份验证（AuthN）：身份证明（密码,MFA,证书）。
授权（AuthZ）：根据策略和上下文做出"可以/不能"的决定。
PDP/PEP：政策决策点（做出决定）/政策执行点（应用）。
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/Mobile）。
SSO：支持b2b/语句的外部 IdP（SAML/OIDC）。
MFA：TOTP/WebAuthn/SMS（由WebAuthn和TOTP推荐；SMS — fallback).
基于风险的Step-Up：在敏感活动（取款，更改道具）中需要MFA/pe-Auth。

安全实践：

Refresh令牌旋转+带有重用检测器的RT注册表。
Nonce/State+PKCE，用于浏览器流的严格CORS/CSRF。
Short-lived access tokens (5–15 мин) + silent refresh/RT.
用于关键操作的设备绑定（DPoP/mtls-bound tokens）。

示例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）

服务之间的mTLS+SPIFFE/SPIRE用于可持续工作负载ID。
由HSM/KMS签署的短期服务JWT（≤5分钟）；签发审计。
受众分析：JWT仅适用于特定服务/域。
信任区：来自不同地区/特南特的服务是单独的PKI和策略。

5）授权模型： RBAC，ABAC，ReBAC

RBAC（角色→分辨率）：简单而透明（适用于管理面板和操作员）。

ABAC（主体/资源/上下文属性）： 灵活地使用"tenant=……AND region=…AND kyc_tier≥2».

ReBAC（关系）：对复杂所有权（"拥有品牌/资料夹/活动的人"）有用。

建议：混合体-基本的RBAC+上下文的ABAC条件+点点ReBAC关系。

6）政策及其执行（PDP/PEP）

Gateway和服务中的PEP：提取上下文（JWT，任务，IP/ASN，时间，区域，KYC级别），形成PDP请求。

PDP（例如OPA/cedar）获得：

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） Scoops和许可证

命名是：

资源：动作-"wallet：read"，"wallet：transfer"，"bets：place"，"kyc：status。read`.
对于管理员，在隔离域中为"admin："。
对于提供商-'provider： report。read`, `provider:events.push`.

最小特权原则：我们只指定必要的漏洞；"升级"（临时授权）-通过tiket和TTL。

8）多特南特和地区（居住）

令牌包含"tenant"，"region"，"licence"；PDP检查资源是否匹配。
角色/策略-per tenant名称空间（"role：brand_eu/support"）。
按地区划分签名密钥和召回列表；跨区域查询-仅通过受信任的网关。

9）会议和设备管理

Web服务器侧会话商店（绑定到设备/浏览器,旋转标识符）。
Idle/Absolute Timeout（同上，30分钟/24小时）；敏感活动-re-Auth/MFA。
上市活动设备，"退出努力"。
异常：来自不同地区的同时输入，频繁的MFA失败-风险信号。

10）委派和同意（同意）

On-behalf-of（OBO）：该服务代表用户运行（具有单个"sub"/"act"的代理令牌）。
同意：合作伙伴访问数据的显式屏幕，同意召回日志。
临时access-mandates： N小时/天的权利,自动到期。

11）密钥、签名和轮换

带有"kid"的JWKS，自动旋转，在KMS/HSM中存储私有密钥。

算法： JWT的ES256/EdDSA；TLS 1.2+/mTLS.

双键期：在完成客户更新之前接收两个"kid"。
RT和Token Introspection召回重大事件。

12）客户端应用程序安全

SPA: Authorization Code + PKCE, no `implicit`, строгий CORS/Content-Security-Policy.

Mobile： App Attestation/Device Check, RT安全存储,Rute/Jailbrake防护。
Desktop：用于登录的系统浏览器（no embedded web views）, PKCE。

13）方便的SDK合同

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

Token Exchange (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_success_rate`/`mfa_challenge_rate`/`mfa_fail_rate`
`authz_p95_ms`, `authz_denied_rate{reason}`
`invalid_token_rate`, `jwks_skew_ms`, `rt_reuse_detected`
输入异常（新设备，geo-velocity），可疑漏洞。

Logi/Audit（不可更改）：

`who/what/when/where/why`, `decision`, `policy_version`, `token_kid`, `client_id`.
合成导出（调节器/供应商审核）。

15）外围和客户保护

Gateway PEP：限量版，bot/signature检查，CSRF保护，严格的CORS，HSTS。
内部流量：mTLS+服务JWT+有限网络。
Webhooks/外部 collbacks：身体签名（HMAC/JWS），时间窗口，反倒带。

16）典型错误

长寿访问令牌→泄漏。
含义OAuth流入SPA。
没有按键旋转和双键周期。
冗余角色而不是策略（无法审核/解释决策）。
将特南特/地区混为一体"role"或"key"。
在敏感动作上没有MFA。
AuthZ解决方桉缓存,不因角色更改而致残。

17）花花公子（runbooks）

1.JWT签名密钥的损害

立即恢复"kid"，发布新的JWKS，强迫残疾RT/会议，向审计报告。

2.大众的"invalid_token"

检查时钟/寿命、JWKS相关性、腰果故障。

3.输入异常

包括增加风险评分，要求上调，通知用户，暂时限制付款。

4.IdP失败

切换到会话缓存/角色设备,限制新的登录,将当前会话保留到TTL。

18）售前支票清单

[] OIDC/OAuth 2.1与PKCE，短AT，RT轮换，设备绑定的关键操作。

MFA（WebAuthn/TOTP）和步骤，用于推断/道具更改/角色升级。
服务到服务：mTLS+SPIFFE，短期服务JWT。
集中式PDP中的AuthZ政策（RBAC+ABAC/ReBAC）；门户和服务上的PEP。
残疾解决方桉缓存；audit trail不变。
multi tenant/regions：密钥隔离/策略/log,许可证核算。
KMS/HSM中的JWKS/密钥,双键旋转,监视"kid"。
CSRF/CORS/HSTS/Rate-limit/Bot过滤器。
事件花花公子,run按钮revoke/rotate/lockdown。
测试套件：unit （policies）, contract （SDK/flows）, chaos （IdP, JWKS）, e2e （step-up, OBO, revoke）。

19）迷你配置模板

Scope注册表（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]

PDP策略（区域条件）：

yaml deny:
- when: { region: ["NL","BE"] }
actions: ["bets."]

结论

身份验证和授权轮廓不是库，而是平台能力：短寿命令牌和可控密钥，集中式策略及其本地应用，多因素和步进，严格隔离Tenant/Region，审核和遥测。这种设计使更改安全，可以为监管机构解释，并且对产品透明-通过市场和团队进行扩展成为例行操作而不是壮举。

身份验证和授权

结论

联系我们

快速联系

视频即将更新

我们目前正忙于各项项目