Sevity Blog

글로벌하게 유니키한 키를 만들어야 할때, 보통은 uuid를 떠올리지만 snowflake방식을 선택하면 아래와 같은 장점이 있다.

언제 UUID를 쓰고, 언제 Snowflake를 쓰나?

• UUIDv4
  • 단순 분산 식별자(ID)만 필요하고, 시간순 정렬·인덱스 단편화 이슈가 크지 않은 애플리케이션
  • 예: 각종 리소스(사용자·세션·토큰) 식별 등
• Snowflake
  • 고TPS 분산 시스템에서 시간순 처리·인덱스 효율·멱등 ID가 중요할 때
  • 예: 이벤트 로깅, 메시징 시스템, 주문·트랜잭션 ID

OAuth2.0위에서 추가로 설계된 스펙으로 기존 엑세스토큰, 리프레시토큰과 더불어 ID Token을 발행하여 “인증(Authentication)” 기능을 추가한 표준 프로토콜입니다.

• OAuth 2.0이 “리소스 접근 권한(Authorization)”을 다룬다면,
• OIDC는 “사용자 인증(Authentication)”을 다룹니다.

필수 클레임(iss, sub, aud, exp 등) + 요청한 소수의 추가 클레임(예: email, name)

ID Token에 담기는 필드 예시

{
  "iss": "https://auth.gangnamunni.com/",     // 토큰 발급자(Identity Provider)  
  "sub": "248289761001",                       // 사용자 고유 식별자  
  "aud": "points-service-prod",                // 토큰 대상(클라이언트 ID)  
  "exp": 1718865600,                           // 토큰 만료 시각 (Unix timestamp)  
  "iat": 1718862000,                           // 토큰 발급 시각  
  "auth_time": 1718861990,                     // 사용자가 실제 인증한 시각  
  "nonce": "n-0S6_WzA2Mj",                      // 리플레이 공격 방지용 값  
  "email": "janedoe@example.com",              // 요청한 추가 클레임: 이메일  
  "email_verified": true,                      // 이메일 검증 여부  
  "name": "Jane Doe",                          // 요청한 추가 클레임: 이름  
  "preferred_username": "j.doe"                // 요청한 추가 클레임: 사용자명
}

하지만 아래 이유로..

정적 정보: 발급 시점의 정보만 담겨, 사용자가 프로필을 변경해도 토큰에는 반영되지 않음
사이즈 한계: 너무 많은 필드를 넣으면 JWT가 커져 네트워크/성능 부담 ↑
보안 고려: 민감 정보(주소, 휴대폰 등)를 토큰에 영구 저장하면 위험

UserInfo Endpoint 추가

자세한건 다시 api찔러서 확인

서비스 특성에 따라

• ID 토큰만,
• UserInfo만,
• 혹은 둘 다 쓰는 패턴을 자유롭게 선택하시면 됩니다.

UserInfo Endpoint를 왜 추가했나?

• 목적: “로그인한 사용자에 대한 동적·확장 프로필”을 안전하게 조회”
• 동작 방식:
  1. 클라이언트가 access_token을 이용해 /userinfo 호출
  2. 서버가 현재 스코프(scope)·권한에 맞는 최신 프로필(JSON) 반환
• 장점:
  • 최신성: 호출 시점의 유저 정보를 그대로 반영
  • 선택적 노출: scope(email profile phone 등)에 따라 필요한 정보만 제공
  • 토큰 경량화: 민감·대용량 데이터는 토큰이 아니라 API로 분리

/userinfo라는 엔드포인트 이름 자체도 OIDC Core 1.0 사양(섹션 5.3)에 명시된 표준 필드(userinfo_endpoint)입니다. 클라이언트는 .well-known/openid-configuration에서 이 URL을 동적으로 조회(discovery)하도록 되어 있고, 실제 경로는 /userinfo가 아니어도 메타데이터에 정의된 대로 호출하면 됩니다. 즉, /userinfo는 OIDC 스펙에 포함된 공식 기능이며, “스펙 확장”이 아니라 인증과 프로필 조회를 분리하기 위해 설계된 표준입니다

“아웃박스 패턴은 분산 트랜잭션을 쓰지 않고도 데이터베이스 업데이트와 외부 시스템(Kafka나 REST API 등) 호출을 사실상 하나의 트랜잭션처럼 보이게 하는 기법입니다.

1. 비즈니스 로직 DB 쓰기와 동일한 DB 트랜잭션에서 ‘Outbox’ 테이블에 이벤트 메시지를 append(INSERT)
2. 트랜잭션 커밋 시점에 비즈니스 데이터와 Outbox INSERT가 함께 커밋됨
3. 별도 프로세스(Outbox Poller)가 이 테이블을 폴링해서 메시지를 읽고 Kafka 프로듀서나 외부 API를 호출
4. 호출 성공 시 Outbox 레코드의 status=PROCESSED(또는 sent_at) 같은 플래그를 업데이트”

“Outbox 패턴으로 비즈니스 데이터와 이벤트 기록을 하나의 DB 트랜잭션에 묶어 최소-Once 전송을 확보합니다.
이후 Outbox Poller가 Kafka에 이벤트를 보낼 때는 Idempotent Producer(enable.idempotence=true)와 Kafka Transaction API를 활용해, ‘메시지 전송 + 소비 오프셋 커밋’을 하나의 카프카 트랜잭션으로 처리합니다.
마지막으로, 소비 측에서 claimId를 키로 사용하는 idempotent 처리 로직을 적용하면, 네트워크 오류나 재시도 상황에서도 정확히 한 번만 downstream에 반영되는 구조를 완성할 수 있습니다.”