Skip to content

logi가 검증하는 방법 ​

이 페이지는 Zero Trust 개요에서 설명한 원칙이 실제로 어떻게 동작하는지, 그리고 RP(통합 앱)가 무엇을 해야 하는지를 다룹니다. 네 가지 축으로 나뉩니다.


1. 명시적 검증 — "토큰 하나만 믿지 마라" ​

Zero Trust의 1번 규칙: bearer 토큰 문자열 하나만으로는 아무것도 신뢰하지 않는다. RP는 토큰을 받았다고 끝이 아니라, 그것이 진짜이고 이 앱을 위한 것인지 검증해야 합니다.

How it works ​

RP 백엔드가 로그인을 완료할 때 권장 검증 순서:

  1. id_token 서명 검증 — logi의 JWKS 엔드포인트에서 공개키를 가져와 RS256 서명을 확인합니다.
  2. 클레임 검증 — iss(발급자), exp(만료), 그리고 가장 중요한 aud(대상). aud가 내 client_id와 일치해야 합니다. 이게 다른 앱을 위해 발급된 토큰을 내 앱에 밀어넣는 공격(token substitution)을 막습니다.
  3. UserInfo 대조 — GET /oauth/userinfo로 사용자 정보를 가져옵니다.
  4. 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는 prompt=login 으로 기존 세션을 무시하고 재로그인을 강제할 수 있습니다.

    max_age·acr_values 는 아직 지원하지 않습니다

    두 파라미터는 현재 인가 요청에서 읽지 않고 조용히 무시합니다. 재인증을 강제해야 하면 prompt=login 을 쓰세요. discovery 의 acr_values_supported 는 요청 가능한 값이 아니라 발급된 토큰에 실릴 수 있는 acr 값을 알리는 것이며, passkey UV 로그인에서만 나타나므로 RP 는 선택적 클레임으로 다뤄야 합니다.

  • 권한 확장 모니터링 — RP가 이전에 동의받지 않은 scope를 요청하면 Scope Drift 정책이 이를 기록하고 통지합니다.
  • 이상 로그인 탐지 — 국가 변경·처음 보는 기기·짧은 시간 다국가 접속 등을 의심 신호로 탐지하고, 필요 시 계정을 보호합니다.

요약: RP가 해야 할 것 ​

축RP 액션
명시적 검증id_token JWKS 서명 + aud 검증 → userinfo sub 대조
Sender-constrainedRefresh Token 회전 준수, 재사용 금지
디바이스 신뢰모바일 SDK의 App Attest / Play Integrity 흐름 사용
지속 재인증민감 작업에 max_age·prompt=login으로 step-up 요구

→ 통합 체크리스트는 보안 Best Practices에, 위협 분석은 Threat Model에 있습니다.

Identity가 제품의 신뢰를 만듭니다.