32장. JWT 검증과 업무 인가를 분리한다

Resource Server는 JWKS를 받아 JWT signature, issuer, expiry를 검증하지만 서비스의 올바른 audience와 tenant·현장 권한은 별로 확인해야 한다. scope가 handoffs.write여도 actor가 해당 site 소속인지, resource가 같은 tenant인지 검사한다. 관리자 role 하나로 모든 경계를 우회하지 않는다.

security test는 token 없음, 잘못된 issuer·audience, 만료, 아직 유효하지 않음, 서명 key 회전, scope 부족, 다른 tenant resource를 포함한다. JWKS endpoint가 잠시 느릴 때 기존 cached key로 검증 가능한지와 새 key token의 실패 방식을 본다. token 원문과 Authorization header는 log·trace attribute에 남기지 않는다.

browser login은 별 BFF 또는 OAuth client가 담당할 수 있고 API는 access token을 받는다. refresh token을 browser storage에 장기 노출하지 않는다. CORS는 알려진 origin·method·header만 허용하며 CORS를 인증 기능으로 설명하지 않는다. break-glass 권한은 시간 제한, 승인, 상세 audit가 있어야 한다.