커널에서 OAuth2/OpenID 연결

OAuth2를 통한 OIDC는 사용자/클라이언트가 누구인지 증명하고 단기 API 액세스를 제공하는 표준 방법입니다. 플랫폼의 핵심은 중심 기능이됩니다. 고객, 운영자 및 서비스를위한 단일 사인온; 최소 권한; 측정 가능한 위험; 지역 및 라이센스 규정 준수

1) 목표와 원칙

분리 "배치 대 활성화": 코드를 별도로 배포하고 플래그/정책으로 액세스 할 수 있습니다.
단기 토큰 + 보안 업데이트: 누출로 인한 피해를 줄입니다.
다중 테넌트/지역: 모든 아티팩트에는 '테넌트/지역/라이센스' 라는 레이블이 붙어 있습니다.
토큰 위의 정책: 솔루션은 게이트웨이/서비스의 PEP 인 PDP (RBAC/ABAC) 에 의해 이루어집니다.
링크 보호: TLS1. 2 +, 가능한 경우 mSL/DPoP, 엄격한 CORS/CSRF.
관찰 및 감사: 스트림 별, 고객 별, 지역별 가시성.

2) 흐름과 적용 시점

인증 코드 + PKCE (용량/모바일/웹) -사용자 로그인의 기본값.

브라우저가없는 경우 장치 승인 (콘솔/TV/CLI) -

클라이언트 자격 증명 (머신 투 머신) -사용자가없는 서비스 통합.
토큰 교환 (RFC 8693, OBO) -서비스는 사용자를 대신하여 작동합니다.
CIBA/백 채널 (옵션) -리디렉션없이 인증을 푸시하십시오.

• PAR (Pushed Authorization Requests) -권한 부여 매개 변수는 보안 서버 채널을 통해 전송됩니다.
• JWT Secured Authorization-요청 매개 변수가 서명/암호화됩니다.
• JARM-스푸핑에 강한 보호 인증 응답 (JWT).
• RAR (Rich Authorization Requests) - 풍부한 액세스 권한 요청 (세부 권한).

3) 토큰과 우표

• ID 토큰 (OIDC) -입력 한 사람 (클라이언트/전면에만 표시)
• 액세스 토큰 (AT) -행동 권리 (짧은 수명).
• 새로 고침 토큰 (RT) -AT 업데이트; 신뢰할 수있는 환경에만 저장됩니다.

• AT: 5-15 분 (웹/모바일), 2-5 분 (서비스 간).
• RT: 7-30
• ID: 계산해 보세요.

json
{
"iss":"https://auth. core",
"sub":"user_42",
"aud":["wallet","catalog"],
"exp":1730388600,"iat":1730388000,
"tenant":"brand_eu","region":"EE","licence":"EE-A1",
"scp":["wallet:read","bets:place"],     // scopes
"sid ": "sess _ abcd, ""amr": [" pwd,"" webauthn"] ,//login methods
"act":{"sub":"svc. catalog" }//if OBO
}

서명: ES256/EdUSA, 공개 키-JWKS에서 'kid' 및 회전.

4) 세션 개요 및 로그아웃

서버 측 세션 계정 웹 (쿠키 'SameSite = Lax/Strict', 'HttpOnly', 'Secure').
백 채널 로그아웃 + 프론트 채널 로그아웃 (OIDC) -모든 클라이언트의 동기식 종료.
스텝 업 MFA: 민감한 동작으로 반복 점검 ('acr' 증가).
취소 및 감시: 사고로 RT/AT를 즉시 비활성화합니다.

5) 고객 보안

웹/SPA: 승인 코드 + PKCE, 암시 적 없음; 엄격한 CORS/컨텐츠 보안 정책.
모바일: 시스템 브라우저 (AppAuth), 무결성 확인 (App Attestation/DeviceQ), 안전한 RT 스토리지.
데스크톱/CLI/TV: 장치 흐름; OS 비밀 상점에 RT 저장.
AT를 장치/연결에 바인딩하기위한 DPoP 또는 mSL 바운드 토큰.

6) 서비스 서비스

mSL + 짧은 서비스 JWT (aud-scoped), KMS/HSM으로 STS를 발행합니다.
워크로드의 정체성: SPIFFE/SPIRE.

광범위한 정책: 대신 특정 청중과 범위. "

7) 범위 등록 및 동의

명명: '자원: 행동' - '지갑: 읽기', '지갑: 전송', '베팅: 장소', 'kyc: 상태. 읽기 '.

스코프의 가시성과 감도를 설정합니다.

동의 화면은 RAR/Scopes로 조립됩니다. 동의 기록을 유지하고 피드백을 허용하십시

json
{
"type":"wallet. transfer",
"actions":["create"],
"locations":["https://api. core/wallet"],
"datatypes":["payment"],
"resources":[{"wallet_id":"w_123","currency":"EUR","amount_max":1000}]
}

8) 승인 통합 (PDP/PEP)

게이트웨이 API의 PEP는 AT/DPoP/mTLS를 검증하고 컨텍스트 (IP/ASN/region/tenent) 를 풍부하게하여 PDP에 요청합니다.
PDP (OPA/cedar) 는 RBAC/ABAC/ReBAC 정책을 적용하고 설명 및 TTL과 함께 'ALLOW/DENY' 를 반환합니다.
이벤트 별 장애 (역할/규칙 변경) 가있는 PEP (TTL 30-120 초) 의 솔루션 캐시.

9) 멀티 테넌트 및 지역

모든 토큰과 세션에는 '테넌트/지역/라이센스' 라는 레이블이 붙어 있습 PDP는 자원 준수를 검증합니다.
지역별로 별도의 JWKS/키 및 리콜 목록; 신뢰할 수있는 게이트웨이를 통한 교차 지역.
데이터 레지던트 제한: 성찰/취소는 원산지 영역에서 수행됩니다.

10) 프로토콜 증폭

PAR + JAR + JARM-인증 매개 변수 및 응답을 보호합니다.
Nonce/State/PKCE-모든 공공 고객을위한 것입니다.
푸시 된 장치 승인 (위험이 높은).
내성을 통한 외부 통합을위한 최소한의 스탬프 + 불투명 한 옵션을 갖춘 JWT 액세스 토큰.
FAPI와 유사한 관행: 엄격한 서명 알고리즘, TLS/redirect _ uri/PKCE 요구 사항.

11) 오류 및 반환 정책

json
{ "error":"invalid_grant", "error_description":"refresh token reused", "error_code":"RT_REUSE" }

(PHP 3 = 3.0.6, PHP 4)

민감한 엔드 포인트 ('/토큰 ', '/introspect', '/recoke ') 에 대한 속도 제한, 지수 백오프.

12) 관찰 및 감사

• (PHP 3 = 3.0.6, PHP 4)
• 'token _ issuance _ p95 _ ms', 'jwks _ skew _ ms', 'unless _ token _ rate', 'rt _ reuse _ dectived',
• API는 다음과 같이 설명합니다. 'rate _ p95 _ ms', 'vezing _ rate {reason}', 'dpop _ mission _ rate', 'mtls _ fail _ rate'.

고객 _ id ',' grant _ style ',' kid ',' acr/amr ',' tentin/region ',' decision ',' policy _ version ',' aud ',' scp ',' sid ',' trace _ id '.
감사 (변경 불가): 토큰 발행, 권리 확대, 동의 철회, 주요 교체.

13) 주요 관리 및 교체

JWT 서명: KMS/HSM, 'kid' 가 포함 된 JWKS 간행물.
이중 키 기간: IdP, 새로운 서명, 리뷰어는 전환하기 전에 이전 + 새로운 것을 수락합니다.
정기적 인 회전 및 비상 철회; '어린이' 소비 모니터링.

14) 플레이 북 (런북)

1. 서명 키 타협

즉시 '어린이' 를 철회하고, 새로운 강제 장애인 RT/세션, 감사 보고서를 발행하십시오.

2. 대량 'unled _ token '/production 401

시계 정렬 오류, 만료 된 AT, 깨진 JWKS 캐시를 확인하십시오. 'clock _ skew' 내성을 일시적으로 증가시킵니다.

3. RT 재사용

세션을 차단하고 ('sid') 사용자에게 알리고 새 로그인을 위해 스텝 업을 요구하고 조사하십시오.

4. IdP 드롭

"읽기 전용 인증" 모드 사용: 활성 AT를 TTL까지 유지하고 새 로그인을 제한하며 내성 캐시를 확장하십시오.

5. '/토큰 '에 대한 공격

속도 제한/봇 필터를 강화하고 민감한 클라이언트의 mSL/DPoP를 활성화하고 차가운 RT를 별도의 세그먼트로 이동하십시오.

15) 테스트

계약: OIDC 검색, JWKS, OpenID 제공자 설정.
보안: PKCE/nonce/state가 필요합니다. 네거티브 세트 ('redirect _ uri' 대체, RT 재사용).
상호 운용성: 클라이언트 (웹/모바일/CLI), 다른 시간대/로케일.
혼돈: PAR/JARM 고장, JWKS 지연, 즉시 '아이' 회전.
E2E: 스텝 업 MFA, OBO (토큰 교환), 로그아웃 (프론트/백 채널), 취소/회전.

16) 설정 예

yaml issuer: https://auth. core jwks:
rotation_days: 30 alg: ES256 tokens:
access_ttl: 10m refresh_ttl: 14d id_ttl: 5m policies:
require_pkce: true require_par: true require_jarm: true dpop_enabled: true mfa_step_up:
actions: ["wallet:transfer","payout:initiate"]
tenancy:
include_claims: ["tenant","region","licence"]
jwks_per_region: true

yaml scopes:
wallet: read: {desc: "Reading balance"}
wallet: transfer: {desc: "Transfer of funds," sensitive: true, step_up: true}
bets: place: {desc: "Betting"}
kyc:status. read: {desc: "KYC status"}
roles:
player: { allow: [bets:place] }
support: { allow: [wallet:read, kyc:status. read] }
finance: { allow: [wallet:read, wallet:transfer] }

17) 사전 판매 점검표

• PKCE/nonce/state 활성화; PAR/JAR/JARM이 활성화되었습니다.
• AT/RT/TTL ID 세트; RT 회전 + 재사용 감지가 활성화되었습니다.
• 민감한 클라이언트/운영을위한 DPoP 또는 mTLS 바인딩.
• JWKS c 'kid'; 자동 회전 및 키 소비 모니터링.
• 동의/RAR 및 범위 등록; 민감한 활동을위한 스텝 업 MFA.
• PDP/PEP 통합 장애 솔루션 캐시.
• 토큰에는 '테넌트/지역/라이센스' 가 포함되어 있습니다. 거주가 관찰됩니다.
• 관찰 가능성: 지표, 로그, 추적; (PHP 3 = 3.0.6, PHP 4)
• 철회/회전/잠금에 관한 플레이 북; 긴급 로그아웃 버튼.
• 일련의 E2E/chaos/interop 테스트가 스탠드에서 통과되었습니다.

결론

OAuth2/OIDC를 플랫폼 기능으로 포함함으로써 예측 가능한 인증 흐름, 관리 토큰, 균일 한 액세스 정책 및 측정 가능한 위험을 얻을 수 있습니다. RT, 키 로테이션, PAR/JARM/DPoP, 동의 및 스텝 업으로 보호되는 짧은 AT는 보안을 기본값으로 만들고 팀과 파트너에게 진화가 빠르고 고통스럽지 않은 관행입니다.