OIDC(Open ID Connect)

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 스펙에 포함된 공식 기능이며, “스펙 확장”이 아니라 인증과 프로필 조회를 분리하기 위해 설계된 표준입니다