OAuth 2.0 vs OpenID Connect

꽉·2025년 12월 24일
ID TokenJWTOIDCOpenID Connectaccess tokenauthenticationauthorizationclaimsoauth2security

OAuth 2.0 보안 다시읽기 (Flow · OIDC · PKCE)

목록 보기
2/2
post-thumbnail

✨ TL;DR

OAuth 2.0과 OpenID Connect(OIDC)는 자주 함께 언급되지만
목적부터 다르다.

  • OAuth 2.0: 권한 위임(Authorization)
  • OpenID Connect: 사용자 인증(Authentication)

OAuth만으로도 로그인처럼 보이는 기능을 만들 수는 있지만,
실제 서비스 환경에서는 여러 한계와 위험이 생긴다.
OIDC는 이 문제를 해결하기 위해 OAuth 위에 얹어진 인증 레이어다.

🔍 배경 — “OAuth로 로그인도 되는데, 왜 OIDC가 필요할까?”

소셜 로그인을 처음 도입할 때는
OAuth만으로도 충분해 보인다.

  • authorization code 발급
  • access token 획득
  • user info API 호출
  • 로그인 처리 완료

실제로 많은 서비스가 이 방식으로 로그인을 구현하고 있다.

하지만 시간이 지나고 구조를 다시 보면
이 질문이 자연스럽게 떠오른다.

“이게 정말 ‘인증’일까?”

OAuth 문서를 다시 읽어보면
OAuth는 애초에 로그인을 위한 표준이 아니다.

🧭 OAuth 2.0의 역할 다시 보기

OAuth 2.0은 처음부터 끝까지
권한 위임(Authorization) 을 해결하기 위한 프로토콜이다.

즉, OAuth의 핵심 질문은 이것이다.

“이 클라이언트가
이 리소스에 접근해도 되는가?”

OAuth에서 발급되는 Access Token은

  • “누구인가?” 보다는
  • “무엇을 할 수 있는가?”에 가깝다.

⚠️ OAuth만으로 로그인을 구현할 때의 문제점

1️⃣ Access Token은 인증 수단이 아니다

Access Token은 사용자 인증 결과가 아니라
리소스 접근 권한을 표현하는 토큰이다.

  • 토큰 포맷은 구현체마다 다르다
  • 만료·회수·재발급 정책도 제각각
  • 사용자 식별 기준이 명확하지 않다

👉 “이 사용자가 누구인지”를 보장하기 어렵다.

2️⃣ UserInfo API 의존

OAuth 기반 로그인은 보통
UserInfo API 호출에 의존한다.

하지만 이 방식에는 문제가 있다.

  • 네트워크 호출 실패 가능성
  • 토큰 범위(scope)에 따라 반환 정보가 달라짐
  • 인증 시점의 정보인지 보장하기 어려움

3️⃣ 인증 이벤트에 대한 신뢰 부족

OAuth만 사용할 경우 다음 질문에 명확히 답하기 어렵다.

  • 사용자가 언제 인증했는가?
  • 이 인증은 어떤 방식으로 이뤄졌는가?
  • 동일한 인증 세션인가?

👉 인증 자체에 대한 메타 정보가 부족하다.

🧩 OpenID Connect는 무엇을 해결하려 했을까

OpenID Connect(OIDC)는
OAuth 2.0 위에 얹어진 인증 레이어다.

OIDC는 OAuth 흐름을 그대로 사용하면서
다음 요소를 추가한다.

  • ID Token
  • 표준화된 사용자 식별 방식
  • 인증 이벤트에 대한 명확한 정의

🔑 ID Token의 의미

OIDC의 핵심은 ID Token이다.

ID Token은 다음을 보장한다.

  • 이 사용자는 누구인가 (sub)
  • 언제 인증되었는가 (iat, auth_time)
  • 어떤 인증 제공자에서 인증했는가 (iss)
  • 이 토큰을 누가 발급받았는가 (aud)

그리고 이 정보는

  • 서명된 JWT
  • 검증 가능한 형식
    으로 전달된다.

👉 더 이상 UserInfo API 호출에 의존하지 않아도 된다.

🔄 OAuth vs OIDC 비교 정리

구분OAuth 2.0OpenID Connect
목적권한 위임사용자 인증
핵심 토큰Access TokenID Token
사용자 식별비표준표준화됨
인증 시점 정보없음포함
로그인 용도부적합적합

🧠 “그럼 OAuth는 로그인에 쓰면 안 되나?”

쓸 수는 있다.
하지만 다음 전제가 붙는다.

  • 서비스 규모가 작고
  • 인증 보안 요구가 낮고
  • 단순 연동이 목적일 때

서비스가 커질수록

  • 인증 이벤트 추적
  • 보안 감사
  • 토큰 검증 일관성

같은 요구사항이 생기고,
이 시점부터 OAuth만으로는 한계가 분명해진다.

⚠️ 실제 서비스 환경에서 고려해야 할 차이

  • 로그인 상태 검증은 ID Token
  • API 호출 권한은 Access Token
  • 인증과 인가는 분리해서 설계

OIDC는 이 분리를 구조적으로 강제한다.

📦 마무리

OAuth 2.0과 OpenID Connect는
서로 대체 관계가 아니다.

  • OAuth는 “할 수 있는 것”
  • OIDC는 “누구인지”

로그인을 구현한다면
OAuth 위에 OIDC를 얹는 구조가
가장 자연스럽고 안전하다.

이 글은
OAuth를 사용해 로그인 기능을 구현해본 뒤,
OIDC가 왜 등장했는지를 다시 이해하려는 정리다.

📚 참고 문헌

profile
꽉
하나씩 꽉꽉 눌러 담는 실무 개발 노트 ✍️📦
이전 포스트

OAuth 2.0 Authorization Code Flow를 다시 읽어보며

0개의 댓글