🌐 웹 보안 인증 프로토콜 비교: OAuth 2.0 vs OpenID Connect

📘 1. 서론: 웹 인증 프로토콜의 중요성 제기

• 디지털 전환 가속화와 SaaS 기반 서비스 확산으로 사용자 인증(Authentication) 및 권한 위임(Authorization)에 대한 보안 요구 증가
• SNS 연동 로그인(Social Login), 제3자 앱 통합 등의 수요 증가로 OAuth 2.0과 OpenID Connect(OIDC)가 표준 인증 프로토콜로 자리잡음
• OAuth 2.0은 권한 위임 프레임워크 중심, OIDC는 사용자 인증을 확장한 프로토콜로 상호보완적 관계에 해당함
• 두 프로토콜에 대한 명확한 비교를 통해 서비스 보안 설계 시 적합한 선택 기준 수립 가능함

---

📘 2. OAuth 2.0 개요

• 정의: 리소스 소유자의 권한을 제3자 클라이언트가 안전하게 접근할 수 있도록 허용하는 권한 위임 프레임워크
• 표준화 주체: IETF RFC 6749에 의해 정의됨
• 주요 구성요소
  • Resource Owner: 리소스에 대한 접근 권한 보유 사용자
  • Client: 리소스 접근을 원하는 제3자 애플리케이션
  • Authorization Server: 권한을 부여하고 토큰을 발급하는 서버
  • Resource Server: 보호된 리소스를 제공하는 서버
• 인증 기능 부재
  • 사용자 인증은 OAuth 2.0의 기본 목표 아님
  • 클라이언트가 사용자에 대한 정보 보장 불가

---

📘 3. OpenID Connect 개요

• 정의: OAuth 2.0 기반에 사용자의 인증(Authentication)을 추가한 프로토콜
• 표준화 주체: OpenID Foundation
• 추가 요소
  • ID Token: 사용자의 인증 정보를 담은 JWT 형태의 토큰
  • UserInfo Endpoint: 사용자 프로필을 제공하는 엔드포인트
• OAuth 2.0과의 관계: OAuth 2.0을 기반으로 하며, 토큰 처리 및 플로우 대부분 공유

---

📘 4. OAuth 2.0 vs OpenID Connect 비교

비교 항목	OAuth 2.0	OpenID Connect (OIDC)
목적	권한 위임 (Authorization)	인증 + 권한 위임 (Authentication + Authorization)
토큰	Access Token	Access Token + ID Token
사용자 식별	직접 불가능	ID Token을 통해 가능
사용자 정보 조회	리소스 서버 통해 간접 제공	userinfo 엔드포인트에서 직접 제공
인증 기능	미지원	인증 표준으로 기능 수행
토큰 형식	제한 없음 (Bearer, JWT 등)	ID Token은 JWT 기반 필수
사용 예	카카오 로그인, Google Drive API 접근 등	Google 로그인, OIDC 기반 SSO, 인증기반 연동 시스템 등
확장성	다양한 권한 부여 방식 지원	OAuth 2.0 확장으로 대부분 기능 호환
보안 고려	PKCE, Client Secret 보호 필요	추가적으로 nonce, state 등 Replay 방지 요소 적용

---

📘 5. 주요 인증 플로우 비교

🔹 OAuth 2.0 Authorization Code Flow

1. 사용자 브라우저가 인증 서버로 이동
2. 사용자 권한 승인
3. 서버가 Authorization Code 발급
4. 클라이언트가 이 코드로 Access Token 요청
5. Access Token을 통해 보호 자원 접근

🔹 OIDC Authorization Code Flow (with ID Token)

1. OAuth 2.0의 플로우와 동일
2. Access Token과 함께 ID Token도 함께 발급됨
3. 클라이언트는 ID Token을 통해 사용자의 인증 여부와 프로필 확인 가능

---

📘 6. 보안 요소 및 고려사항

• OAuth 2.0은 인증 자체에 대한 신뢰 구조 부재 → ID Token 부재 시 사용자 인증 신뢰 불가
• OpenID Connect는 인증 메커니즘 보완으로 ID Token 서명 검증, nonce값 포함, scope 처리 등을 통해 보안 강화
• 둘 모두 CSRF, Token 탈취, Phishing 등 공격에 대비한 클라이언트 구현 필요

---

📘 7. 실제 적용 사례

기업/플랫폼	적용 방식
Google	OIDC + OAuth 2.0 기반 통합 로그인, Gmail/Calendar API 접근 시 Access Token 활용
Microsoft Azure AD	기업용 인증 OIDC 활용, 리소스 접근은 OAuth 2.0으로 처리
Facebook	OAuth 2.0 기반 Social Login 구현, 인증 목적보다는 권한 위임 중심
국내 금융기관	OAuth 2.0 기반 마이데이터 시스템 구성, 보안성 강화 위해 OIDC 연계 검토

---

📘 8. 결론 및 제언

• OAuth 2.0은 권한 위임 중심 프로토콜로 API 접근, 리소스 보호를 위한 표준 구조로 적합함
• OpenID Connect는 사용자 인증까지 포괄하는 통합 인증 솔루션으로, SSO, 사용자 정보 확인이 요구되는 환경에 적합함
• 보안과 신뢰성이 요구되는 서비스에서는 반드시 OIDC를 기반으로 사용자 인증 보장 필요
• 서비스 목적에 따라 프로토콜을 혼용하거나, OIDC의 확장성을 고려하여 향후 인증 체계 확장 용이성 확보 바람직함

---