[카카오 로그인] OIDC 최소 scope·sub 안정성·JWKS·client secret 회전 문의

REST API
1

안녕하세요.

이 문의는 특정 앱에서 발생한 오류가 아니라 공개 OIDC 계약에 대한 일반 확인 요청입니다. 공개 게시물에는 앱 ID와 실제 서비스 URL을 포함하지 않았습니다.

카카오 로그인 OIDC를 기존 패스키 계정의 보조 로그인 수단으로 도입하기 전에 최소정보 사용과 운영 계약을 확인하고자 합니다. 소셜 계정만으로 신규 계정을 만들거나 이메일로 계정을 병합하지 않고, 사용자가 최근 패스키 인증 후 명시적으로 연결한 경우에만 로그인 수단으로 사용할 예정입니다.

공식 문서에서 다음 내용을 확인했습니다.

  • OpenID Connect를 활성화하면 access token과 ID token이 함께 발급됨
  • ID token의 sub는 해당 사용자의 회원번호
  • iss, aud, exp, nonce, JWKS kid와 RS256 서명을 검증
  • nickname, profile image, email은 동의항목과 사용자 동의가 필요한 선택 claim
  • JWKS는 일정 기간 cache하고 지나치게 빈번한 요청을 피하도록 권고
  • REST API key의 client secret 기능이 활성화된 경우 token 발급 요청에 client secret을 포함

예정한 개인정보 최소화 방식은 다음과 같습니다.

  • authorization code flow, PKCE S256, one-time state, nonce 사용
  • scope=openid만 요청하고 이메일·닉네임·프로필 사진 동의항목은 신청하지 않음
  • 검증된 raw sub는 서버에서 즉시 HMAC digest로 변환하고 원문을 저장하지 않음
  • access token, refresh token, ID token, authorization code를 영구 저장하지 않음
  • User Information API를 호출하지 않음
  • token 요청 결과가 불명확한 timeout에는 authorization code를 자동 재사용하지 않음

아래 항목을 확인 부탁드립니다.

  1. OIDC가 활성화된 REST API 앱에서 authorization code 요청에 scope=openid만 사용해 ID token을 발급받는 방식이 공식 지원됩니까?
  2. 별도 개인정보 동의항목을 설정하지 않아도 ID token에 식별용 sub가 필수로 포함됩니까?
  3. 이메일·닉네임·프로필 사진 동의항목을 신청하지 않은 경우 해당 선택 claim이 ID token에 포함되지 않는다고 이해해도 됩니까?
  4. sub는 같은 앱에서 카카오계정의 수명 동안 장기 식별자로 사용할 수 있습니까? 앱 소유자·사업자·REST API key 변경 또는 앱 이전 시 sub가 변경될 수 있습니까?
  5. JWKS cache 권장 기간 또는 HTTP cache header 계약이 있습니까? 검증 중 알 수 없는 kid를 받은 경우 JWKS를 한 번 새로 조회한 뒤 실패 처리하는 방식이 권장됩니까?
  6. token 요청이 timeout으로 끝나 결과를 알 수 없는 경우 같은 authorization code로 자동 재시도하지 않고 사용자에게 로그인을 다시 시작하도록 하는 방식이 권장됩니까?
  7. client secret 회전 시 old/new secret을 동시에 유효하게 유지하는 기간이나 공식 무중단 회전 절차가 있습니까?
  8. 검증된 raw sub 대신 HMAC digest만 저장하고 token·authorization code는 callback 처리 후 폐기하는 방식이 카카오 로그인 ID token 검증·회원 식별 계약과 충돌하지 않습니까?

가능하면 적용되는 공식 개발문서·운영정책 URL도 함께 안내 부탁드립니다.

감사합니다.

2

[@tim.l @woody.ho]

3
1. OIDC가 활성화된 REST API 앱에서 authorization code 요청에 scope=openid만 사용해 ID token을 발급받는 방식이 공식 지원됩니까?

네, 지원 됩니다.

2. 별도 개인정보 동의항목을 설정하지 않아도 ID token에 식별용 sub가 필수로 포함됩니까?

네, OIDC 표준 스펙에 따라 제공 되기에 문의 주신 바와 같은 기본 스펙 관련 내용은 기본적으로 표준 스펙에 따라 지원되고 있는 점 참고 부탁드립니다.

3. 이메일·닉네임·프로필 사진 동의항목을 신청하지 않은 경우 해당 선택 claim이 ID token에 포함되지 않는다고 이해해도 됩니까?

네, 맞습니다.

4. sub는 같은 앱에서 카카오계정의 수명 동안 장기 식별자로 사용할 수 있습니까? 앱 소유자·사업자·REST API key 변경 또는 앱 이전 시 sub가 변경될 수 있습니까?

네, sub은 회원번호(Service UserID)이며, 앱과 계정에 종속적인 식별자로서 동일 앱 내의 회원식별을 위한 값 입니다.
이 값은 동일 앱 내 앱 키의 변화에 영향을 받지 않습니다.

5. JWKS cache 권장 기간 또는 HTTP cache header 계약이 있습니까? 검증 중 알 수 없는 kid를 받은 경우 JWKS를 한 번 새로 조회한 뒤 실패 처리하는 방식이 권장됩니까?

검증 오류 시 갱신하시기 보다 1개월 주기로 갱신하실 것을 추천 드립니다.

6. token 요청이 timeout으로 끝나 결과를 알 수 없는 경우 같은 authorization code로 자동 재시도하지 않고 사용자에게 로그인을 다시 시작하도록 하는 방식이 권장됩니까?

네, 일반적으로 대부분 timeout 발생 원인이 서비스측에서 발생 되기에 이를 인지하여 원인을 파악해 보실 것을 추천드리며,
인가코드는 성공 실패 여부와 무관히 단 한번만 사용 가능하므로 이를 재시도 하는 것 보다 다시 로그인 하도록 하실 것을 권장드립니다.

7. client secret 회전 시 old/new secret을 동시에 유효하게 유지하는 기간이나 공식 무중단 회전 절차가 있습니까?

현재 client secret 다수를 동시에 유요하게 두는 기능은 제공하고 있지 않습니다.
만약, client secret이 유출 된 경우라면 이를 무중단 처리하실 것이 아닌 즉시 사용을 중시 하는 방식으로 진행하셔야 할것 같습니다. 예를들어 서비스측 장애 최소화를 위해 앱 키와 client secret 셋트를 하나 더 생성하여 교체 하는 방법을 이용하실 수 있습니다.

8. 검증된 raw sub 대신 HMAC digest만 저장하고 token·authorization code는 callback 처리 후 폐기하는 방식이 카카오 로그인 ID token 검증·회원 식별 계약과 충돌하지 않습니까?

digest 생성 후 이 값만 저장하시는 것은 서비스측 컴플라이언스에 따라 기호에 맞게 처리하시면 됩니다.
그 외, 토큰과 인가코드 또한 서비스측 기호에 맞게 처리하시면 됩니다.

OIDC 공식 가이드 문서:
https://developers.kakao.com/docs/ko/kakaologin/rest-api?utm_source=chatgpt.com#oidc