logi가 검증하는 방법
이 페이지는 Zero Trust 개요에서 설명한 원칙이 실제로 어떻게 동작하는지, 그리고 RP(통합 앱)가 무엇을 해야 하는지를 다룹니다. 네 가지 축으로 나뉩니다.
1. 명시적 검증 — "토큰 하나만 믿지 마라"
Zero Trust의 1번 규칙: bearer 토큰 문자열 하나만으로는 아무것도 신뢰하지 않는다. RP는 토큰을 받았다고 끝이 아니라, 그것이 진짜이고 이 앱을 위한 것인지 검증해야 합니다.
How it works
RP 백엔드가 로그인을 완료할 때 권장 검증 순서:
id_token서명 검증 — logi의 JWKS 엔드포인트에서 공개키를 가져와 RS256 서명을 확인합니다.- 클레임 검증 —
iss(발급자),exp(만료), 그리고 가장 중요한aud(대상).aud가 내client_id와 일치해야 합니다. 이게 다른 앱을 위해 발급된 토큰을 내 앱에 밀어넣는 공격(token substitution)을 막습니다. - UserInfo 대조 —
GET /oauth/userinfo로 사용자 정보를 가져옵니다. sub일치 확인 —id_token.sub == userinfo.sub인지 확인합니다.
accessToken 받음
↓ ❌ 여기서 멈추지 마세요
id_token 서명(JWKS) → iss/exp/aud 검증 → userinfo → sub 일치
↓ ✅ 이제서야 신뢰자세한 백엔드 통합은 권장 아키텍처와 보안 Best Practices를 참고하세요.
2. Sender-constrained 토큰 — 탈취돼도 못 쓰게
일반적인 bearer 토큰은 "들고 있으면 누구나 쓸 수 있다"는 약점이 있습니다. logi는 민감한 흐름에서 토큰을 클라이언트의 키에 묶어, 토큰만 훔쳐서는 사용할 수 없게 합니다.
How it works
- DPoP — 클라이언트가 키쌍을 만들고, 요청마다 그 키로 서명한 증명(
DPoP헤더)을 함께 보냅니다. 토큰은 그 공개키 지문(cnf.jkt)에 바인딩됩니다. 키(개인키)가 없으면 토큰을 재사용할 수 없습니다. - 재사용 감지 — Refresh Token은 회전(rotation)되며, 한 번 쓴 토큰이 다시 나타나면 체인 전체를 무효화합니다. 도난 시나리오에서 자동 차단됩니다.
이 두 가지가 합쳐져, 토큰 문자열 유출 = 즉시 계정 장악이라는 bearer의 근본 약점을 제거합니다.
3. 디바이스 신뢰
"사용자는 믿되 디바이스는 검증하라" — logi는 요청이 진짜 우리 앱, 진짜 기기에서 왔는지 플랫폼 증명으로 확인합니다.
How it works
- iOS — App Attest — Apple 하드웨어가 서명한 증명을 서버가 Apple Root 인증서 체인까지 검증합니다. 변조된/위조된 앱은 통과하지 못합니다.
- Android — Play Integrity — Google이 기기·앱 무결성 판정(verdict)을 서명해 발급하고, 서버가 이를 검증합니다.
- Passkey (WebAuthn) — 생체인증(Face ID/지문) 기반의 phishing-resistant 인증. 피싱 사이트에서는 origin이 다르므로 인증기가 서명을 거부합니다. 비밀번호·OTP보다 강력합니다.
Passkey는 origin에 묶이고 재사용이 불가능해, logi가 비밀번호 대신 권장하는 기본 인증 수단입니다.
4. 지속 재인증
인증은 로그인 순간의 일회성 이벤트가 아닙니다. logi는 민감도에 따라 세션 중에도 다시 확인합니다.
How it works
- Step-up 재인증 — 보안 설정 변경 같은 민감 작업은 최근(15분 이내) passkey UV 또는 OTP/백업코드 확인을 다시 요구합니다. 탈취된 세션 쿠키가 무기한 권한을 갖지 못하게 합니다.
- 표준 파라미터로 제어 — RP는 OIDC 표준 파라미터로 인증 강도를 요구할 수 있습니다:
prompt=login— 기존 세션을 무시하고 재로그인 강제max_age=<초>— 마지막 인증이 이 시간보다 오래됐으면 재인증 요구
- 권한 확장 모니터링 — RP가 이전에 동의받지 않은 scope를 요청하면 Scope Drift 정책이 이를 기록하고 통지합니다.
- 이상 로그인 탐지 — 국가 변경·처음 보는 기기·짧은 시간 다국가 접속 등을 의심 신호로 탐지하고, 필요 시 계정을 보호합니다.
요약: RP가 해야 할 것
| 축 | RP 액션 |
|---|---|
| 명시적 검증 | id_token JWKS 서명 + aud 검증 → userinfo sub 대조 |
| Sender-constrained | Refresh Token 회전 준수, 재사용 금지 |
| 디바이스 신뢰 | 모바일 SDK의 App Attest / Play Integrity 흐름 사용 |
| 지속 재인증 | 민감 작업에 max_age·prompt=login으로 step-up 요구 |
→ 통합 체크리스트는 보안 Best Practices에, 위협 분석은 Threat Model에 있습니다.