인증 및 인증

신뢰할 수있는 AuthN/AuthZ 루프는 귀하가 누구인지 (인증) 및 수행 할 수있는 작업 (인증) 에 대한 단일 진실입니다. 많은 브랜드, 지역, 통합 및 높은 규제 요구 사항이있는 플랫폼에서이 윤곽은 "서비스에 의한 if-s의 산란" 이 아니라 정치인에 의해 모듈 식, 관찰 및 관리되어야합니다.

1) 기본 용어 및 역할

식별 (ID): 식별 (사용자, 서비스, 공급자).
인증 (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 (항상
• SSO: b2b/연산자를위한 외부 IdP 지원 (SAML/OIDC).
• MFA: TOTP/WebAuthn/SMS (WebAuthn 및 TOTP 권장; SMS-대체).
• 위험 기반 스텝 업: 민감한 조치 (자금 인출, 세부 사항 변경) 에는 MFA/pe-Auth가 필요합니다.

• 재사용 탐지기로 토큰 회전 + RT 레지스트리를 새로 고침하십시오.
• Nonce/State + PKCE, 브라우저 스트림에 대한 엄격한 CORS/CSRF.
• 단기 액세스 토큰 (5-15
• 중요한 작업을위한 장치 바인딩 (DPoP/mtls 바운드 토큰).

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) 서비스 서비스 인증 (mSL, SPIFFE, JWT)

안정적인 워크로드 식별자를위한 서비스 간 mTLS + SPIFFE/SPIRE.
HSM/KMS가 서명 한 짧은 기간 (약 5 분) 의 서비스 JWT; 발행 감사.
청중 범위: JWT는 특정 서비스/도메인에만 적합합니다.
신탁 영역: 다른 지역/임차인의 서비스-별도의 PKI 및 정책.

5) 승인 모델: RBAC, ABAC, ReBAC

RBAC (역할 → 권한): 간단하고 투명한 (관리자 패널, 운영자에게 적합).
ABAC (주제/리소스/컨텍스트 속성): "테넌트 =... AND 지역 =... AND 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) 스코프와 해상도

• 리소스: 액션- '지갑: 읽기', '지갑: 전송', '베팅: 장소', 'kyc: 상태. 읽기 '.
• 관리자 - '관리자:' 독립형 도메인입니다.
• 공급자- '공급자: 보고서. ',' 제공자: 이벤트를 읽으십시오. 밀어 붙이기 '.

최소 권한의 원칙: 필요한 범위 만 할당합니다. "에스컬레이션" (임시 권리 확장) -티켓 및 TTL.

8) 멀티 테넌트 및 지역 (거주)

토큰에는 '테넌트', '지역', '라이센스' 가 포함됩니다. PDP는 리소스와의 대응을 확인합니다.
역할/정책-임차인 당 네임 스페이스 ('역할: 브랜드 _ eu/지원').
지역별 서명 키 및 취소 목록 분리; 신뢰할 수있는 게이트웨이를 통해서만 지역 간 요청.

9) 세션 및 장치 관리

웹을위한 서버측 세션 저장소 (장치/브라우저 바인딩, 식별자 회전).
유휴/절대 시간 초과 (예: 30 분/24 시간); 민감한 행동-re-Auth/MFA.
활성 장치 목록, "모두에서 나가기".
변칙성: 다른 지역의 동시 입력, 빈번한 MFA 딥-위험 신호.

10) 대표단 및 동의 (동의)

대신 (OBO): 서비스는 사용자를 대신하여 작동합니다 (별도의 '하위 '/' 행위' 가있는 프록시 토큰).
동의: 파트너가 데이터에 액세스하기위한 명시 적 화면, 리콜 동의 로그.
임시 액세스 명령: N 시간/일에 대한 권리가 자동으로 만료됩니다.

11) 키, 서명 및 회전

KMS/HSM에 'kid', 자동 회전, 개인 키 저장이있는 JWKS.
알고리즘: JWT 용 ES256/EdDSA; TLS 1. 2 +/mTLS.
이중 키 기간: 고객 업그레이드가 완료되기 전에 두 어린이 모두 수락하십시오.
RT와 토큰 성찰은 중요한 사건에 대해 회상합니다.

12) 클라이언트 응용 프로그램 보

통신: 승인 코드 + PKCE, '암시 적' 없음, стро보안 코드/콘텐츠-보안 정책.
모바일: 앱 인증/장치 점검, 안전한 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) 관찰 및 감사

• (PHP 3 = 3.0.6, PHP 4)
• (PHP 3 = 3.0.6, PHP 4)
• 'unless _ token _ rate', 'jwks _ skew _ ms', 'rt _ reuse _ detected'
• 입력의 변칙적 (새로운 장치, 지리 속도), 의심스러운 범위.

• '누가/언제/언제/왜/왜', '결정', '정책 _ 버전', '토큰 _ kid', '클라이언트 _ id'.
• 규정 준수 내보내기 (규제 기관/공급 업체 감사).

15) 주변 및 고객 보호

게이트웨이 PEP: 요율 제한, 봇/서명 점검, CSRF 보호, 엄격한 CORS, HSTS.
내부 트래픽: mSL + 서비스 JWT + 제한된 네트워크.
웹 후크/외부 콜백: 신체 서명 (HMAC/JWS), 시간 창, 재생 방지.

16) 전형적인 오류

장기 액세스 토큰 → 누출.
SPA의 암시 적 OAuth 흐름.
키 회전 및 이중 키 기간이 없습니다.
정책 대신 하드 코어 역할 (결정을 감사/설명하는 것은 불가능합니다).
하나의 '역할' 또는 '키' 로 세입자/지역을 혼합합니다.
민감한 행동에 대한 강화 MFA가 없습니다.
AuthZ 솔루션은 역할 변경 장애없이 캐시합니다.

17) 플레이 북 (런북)

1. JWT 서명 키 타협

즉각적인 철회, 새로운 JWKS 출판, 강제 RT/세션 장애, 감사 보고서.

2. 대량 '유효하지 않음'

클럭 오정렬/수명, JWKS 관련성, 캐시 충돌을 확인하십시오.

3. 입력 이상

증가 된 위험 점수를 활성화하고, 스텝 업이 필요하며, 사용자에게 알리고, 일시적으로 지불을 제한하십시오.

4. IdP 실패

세션 캐시/역할 장치로 전환하고 새 로그인을 제한하며 활성 세션을 TTL로 유지하십시오.

18) 사전 판매 점검표

• OIDC/OAuth 2. 1 PKCE, 짧은 AT, RT 회전, 중요한 작업을위한 장치 바인딩.
• MFA (WebAuthn/TOTP) 및 세부 사항/역할 에스컬레이션의 출력/변경을위한 스텝 업.
• 서비스: mSL + SPIFFE, 단기 서비스 JWT.
• 중앙 집중식 PDP의 AuthZ 정책 (RBAC + ABAC/ReBAC); 게이트웨이 및 서비스에 대한 PEP.
• 장애 솔루션 캐시; 감사 흔적을 변경할 수 없습니다.
• 다중 테넌트/지역: 키/정책/로그 격리, 라이센스 회계.
• KMS/HSM의 JWKS/키, 듀얼 키 회전, 모니터링 'kid'.
• 주변의 CSRF/CORS/HSTS/Rate-limited/bot 필터.
• 인시던트 플레이 북, 폐기/회전/잠금 실행 버튼.
• 테스트 제품군: 단위 (정책), 계약 (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."]

결론

인증 및 인증 루프는 라이브러리가 아니라 플랫폼 기능입니다. 단기 토큰 및 관리 키, 중앙 집중식 정책 및 해당 로컬 응용 프로그램, 다 인자 및 스텝 업, 세입자/지역의 엄격한 격리, 감사 및 원격 측정. 이 디자인은 변경 사항을 안전하고 규제 기관에 설명 할 수 있으며 제품에 투명하게 설명합니다. 시장과 명령에 따른 스케일링은 위업이 아닌 일상적인 작업이됩니다.