OAuth 2.0 vs. OpenID Connect

개요 및 역사적 배경

OAuth 2.0

OAuth 2.0은 2012년에 IETF(Internet Engineering Task Force)에서 RFC 6749로 표준화된 인가(Authorization) 프레임워크이다. 이는 2007년에 발표된 OAuth 1.0의 후속 버전으로, 더 단순하고 확장 가능한 구현을 목표로 개발되었다. OAuth 2.0은 애플리케이션이 사용자 데이터에 접근할 수 있는 권한을 안전하게 위임하는 메커니즘을 제공한다.

OpenID Connect

OpenID Connect(OIDC)는 2014년 OpenID Foundation에서 공식 발표한 OAuth 2.0 위에 구축된 ID 인증 레이어이다. OAuth 2.0이 주로 인가에 초점을 맞추고 있는 반면, OpenID Connect는 인증(Authentication)과 신원 확인 기능을 추가했다. OIDC는 이전 버전인 OpenID 2.0의 복잡성을 해결하고, OAuth 2.0과의 호환성을 제공하기 위해 개발되었다.

주요 목적 및 용도

OAuth 2.0의 주요 목적

OAuth 2.0은 기본적으로 인가(Authorization) 프레임워크이다. 즉, 사용자가 자신의 데이터에 대한 접근 권한을 타사 애플리케이션에 안전하게 위임할 수 있도록 하는 것이 주요 목적이다.

구체적으로:

  • 사용자 비밀번호를 공유하지 않고 특정 리소스에 대한 접근 권한 부여
  • 타사 애플리케이션의 접근 범위(scope) 제한
  • 언제든지 접근 권한 취소 가능
  • 클라이언트 타입에 따른 다양한 인가 흐름(grant type) 제공

OpenID Connect의 주요 목적

OpenID Connect는 OAuth 2.0을 확장하여 인증(Authentication) 기능을 추가한 프로토콜이다.

주요 목적은:

  • 사용자의 신원 확인 및 인증
  • 표준화된 사용자 정보 제공
  • 단일 계정으로 여러 서비스 로그인(SSO, Single Sign-On) 지원
  • ID 토큰을 통한 인증 상태 검증

핵심 개념 및 컴포넌트

  • OAuth 2.0 핵심 컴포넌트
    1. 리소스 소유자(Resource Owner): 보호된 리소스에 대한 접근 권한을 가진 사용자
    2. 클라이언트(Client): 사용자의 리소스에 접근하려는 애플리케이션
    3. 리소스 서버(Resource Server): 보호된 리소스를 호스팅하는 서버
    4. 인가 서버(Authorization Server): 클라이언트에게 액세스 토큰을 발급하는 서버
    5. 액세스 토큰(Access Token): 리소스에 접근하기 위한 자격 증명
    6. 리프레시 토큰(Refresh Token): 새로운 액세스 토큰을 얻기 위한 토큰
    7. 스코프(Scope): 클라이언트가 요청하는 접근 권한의 범위
  • OpenID Connect 추가 컴포넌트
    OAuth 2.0의 모든 컴포넌트를 포함하며, 추가로:
    1. ID 토큰(ID Token): 사용자 인증 정보를 포함하는 JWT(JSON Web Token)
    2. 클레임(Claims)**: 사용자에 대한 정보(이름, 이메일 등)
    3. UserInfo 엔드포인트**: 인증된 사용자에 대한 추가 정보를 제공하는 API
    4. OP(OpenID Provider)**: 사용자 인증 및 ID 토큰 발급 서비스
    5. RP(Relying Party)**: OpenID Provider를 통해 인증을 요청하는 클라이언트

프로토콜 흐름 비교

  • OAuth 2.0 기본 흐름(인가 코드 방식)
    1. 클라이언트가 사용자를 인가 서버로 리디렉션
    2. 사용자가 인가 서버에서 인증하고 클라이언트에 권한 부여
    3. 인가 서버가 인가 코드와 함께 사용자를 클라이언트로 리디렉션
    4. 클라이언트가 인가 코드를 사용하여 인가 서버에 액세스 토큰 요청
    5. 인가 서버가 액세스 토큰(및 선택적으로 리프레시 토큰) 발급
    6. 클라이언트가 액세스 토큰을 사용하여 리소스 서버에서 데이터 접근
  • OpenID Connect 흐름 OAuth 2.0의 흐름을 기반으로 하며, 추가로:
    1. 클라이언트가 인가 요청 시 openid 스코프 포함
    2. 사용자 인증 후, 인가 서버는 액세스 토큰과 함께 ID 토큰도 발급
    3. 클라이언트는 ID 토큰을 검증하여 사용자 인증 확인
    4. 필요한 경우 액세스 토큰을 사용하여 UserInfo 엔드포인트에서 추가 사용자 정보 요청

주요 차이점

  1. 목적 및 범위

    • OAuth 2.0: 인가(권한 위임)에 초점
    • OpenID Connect: 인증(신원 확인) + 인가(OAuth 2.0)

  2. 토큰 유형

    • OAuth 2.0: 주로 액세스 토큰과 리프레시 토큰 사용
    • OpenID Connect: 액세스 토큰, 리프레시 토큰 외에 ID 토큰 추가

  3. 표준화 수준

    • OAuth 2.0: 핵심 프레임워크는 표준화되어 있지만, 구현 세부사항은 서비스 제공자마다 다를 수 있음
    • OpenID Connect: 더 엄격한 표준화로 구현 일관성 제공

  4. 사용자 정보

    • OAuth 2.0: 사용자 정보 형식에 대한 표준 없음, 서비스 제공자마다 다른 API 및 응답 형식
    • OpenID Connect: 표준화된 사용자 정보 클레임 및 UserInfo 엔드포인트 정의

  5. 상호 운용성

    • OAuth 2.0: 서비스 간 인가 흐름은 일관적이나, 리소스 접근 방식은 다를 수 있음
    • OpenID Connect: 더 높은 상호 운용성, 다양한 OpenID Provider 간 쉬운 전환 가능

사용 사례 및 적용 시나리오

OAuth 2.0 적합한 사례

  • API 접근 위임: 제3자 애플리케이션이 사용자 데이터에 접근하는 경우
  • 마이크로서비스 간 통신: 서비스 간 인가 관리
  • 리소스 공유 플랫폼: 사진, 문서 등의 사용자 리소스 공유
  • 제한된 접근 권한: 특정 리소스에 대한 세분화된 접근 제어 필요 시

예시: 사용자가 서드파티 앱에 자신의 Google Drive 파일에 대한 접근 권한을 부여하는 경우

OpenID Connect 적합한 사례

  • 사용자 인증이 필요한 애플리케이션: 로그인 기능 구현
  • Single Sign-On(SSO): 여러 애플리케이션 간 통합 로그인
  • 사용자 정보가 필요한 서비스: 사용자 프로필 정보 획득
  • B2B 및 엔터프라이즈 시스템: 기업 내 ID 관리 및 접근 제어

예시: “Google로 로그인” 또는 “Facebook으로 로그인” 기능 구현

구현 예시

OAuth 2.0 구현 (Node.js)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

// OAuth 2.0 인가 코드 흐름 구현 예시
const express = require('express');
const axios = require('axios');
const app = express();

// OAuth 구성
const clientId = 'your_client_id';
const clientSecret = 'your_client_secret';
const redirectUri = 'http://localhost:3000/callback';
const authServerUrl = 'https://authorization-server.com';

// 인가 요청 시작
app.get('/auth', (req, res) => {
  const authUrl = new URL(`${authServerUrl}/authorize`);
  authUrl.searchParams.append('response_type', 'code');
  authUrl.searchParams.append('client_id', clientId);
  authUrl.searchParams.append('redirect_uri', redirectUri);
  authUrl.searchParams.append('scope', 'read write');
  authUrl.searchParams.append('state', 'random_state_string');
  
  res.redirect(authUrl.toString());
});

// 콜백 처리
app.get('/callback', async (req, res) => {
  const { code } = req.query;
  
  try {
    // 코드를 토큰으로 교환
    const tokenResponse = await axios.post(`${authServerUrl}/token`, {
      grant_type: 'authorization_code',
      code,
      redirect_uri: redirectUri,
      client_id: clientId,
      client_secret: clientSecret
    });
    
    const { access_token, refresh_token } = tokenResponse.data;
    
    // 액세스 토큰을 사용하여 리소스 접근
    const resourceResponse = await axios.get('https://resource-server.com/api/resource', {
      headers: { Authorization: `Bearer ${access_token}` }
    });
    
    res.json({
      resource: resourceResponse.data,
      tokens: { access_token, refresh_token }
    });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

app.listen(3000);

OpenID Connect 구현 (Node.js)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

// OpenID Connect 구현 예시
const express = require('express');
const axios = require('axios');
const jwt = require('jsonwebtoken');
const app = express();

// OIDC 구성
const clientId = 'your_client_id';
const clientSecret = 'your_client_secret';
const redirectUri = 'http://localhost:3000/callback';
const oidcProviderUrl = 'https://openid-provider.com';

// 인증 요청 시작
app.get('/login', (req, res) => {
  const authUrl = new URL(`${oidcProviderUrl}/authorize`);
  authUrl.searchParams.append('response_type', 'code');
  authUrl.searchParams.append('client_id', clientId);
  authUrl.searchParams.append('redirect_uri', redirectUri);
  authUrl.searchParams.append('scope', 'openid profile email');
  authUrl.searchParams.append('state', 'random_state_string');
  
  res.redirect(authUrl.toString());
});

// 콜백 처리
app.get('/callback', async (req, res) => {
  const { code } = req.query;
  
  try {
    // 코드를 토큰으로 교환
    const tokenResponse = await axios.post(`${oidcProviderUrl}/token`, {
      grant_type: 'authorization_code',
      code,
      redirect_uri: redirectUri,
      client_id: clientId,
      client_secret: clientSecret
    });
    
    const { access_token, id_token, refresh_token } = tokenResponse.data;
    
    // ID 토큰 검증 (간단한 예시)
    const decodedIdToken = jwt.decode(id_token);
    
    // UserInfo 엔드포인트에서 추가 정보 가져오기
    const userInfoResponse = await axios.get(`${oidcProviderUrl}/userinfo`, {
      headers: { Authorization: `Bearer ${access_token}` }
    });
    
    res.json({
      user: {
        id: decodedIdToken.sub,
        ...decodedIdToken,
        ...userInfoResponse.data
      },
      tokens: { access_token, id_token, refresh_token }
    });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

app.listen(3000);

보안 고려사항

  • OAuth 2.0 보안 고려사항

    1. CSRF(Cross-Site Request Forgery) 공격: state 파라미터를 사용하여 방지
    2. 액세스 토큰 노출: HTTPS 사용 및 안전한 토큰 저장
    3. 리디렉션 URI 검증: 정확한 리디렉션 URI 등록 및 검증
    4. 클라이언트 인증: 클라이언트 시크릿 보호

  • OpenID Connect 추가 보안 고려사항

    1. ID 토큰 서명 검증: 토큰 서명 및 발행자 검증
    2. JWT 클레임 검증: aud(대상), iss(발행자), exp(만료 시간) 등 확인
    3. PKCE(Proof Key for Code Exchange): 모바일/SPA 애플리케이션의 보안 강화
    4. 프런트 채널 및 백 채널 로그아웃: 세션 관리 및 로그아웃 처리

장단점 비교

OAuth 2.0

장점:

  • 간단하고 유연한 구현
  • 다양한 클라이언트 타입 지원
  • 널리 채택되어 생태계가 풍부함
  • 리소스 접근에 대한 세분화된 제어

단점:

  • 인증 메커니즘 부재
  • 구현 세부사항의 불일치
  • 토큰 형식 및 검증 방법 미지정
  • 추가 기능 구현 시 복잡성 증가

OpenID Connect

장점:

  • 표준화된 인증 제공
  • ID 토큰으로 인증 상태 검증 가능
  • 사용자 정보에 대한 표준화된 클레임
  • OAuth 2.0과의 완벽한 호환성

단점:

  • OAuth 2.0보다 복잡한 구현
  • 추가적인 토큰 검증 요구
  • ID 제공자 종속성 가능성
  • 완전한 구현을 위한 추가 스펙 학습 필요

현재 트렌드 및 채택 현황

  1. OAuth 2.0 채택 현황

    • 대부분의 주요 API 제공자들이 채택(Google, Facebook, Twitter, Microsoft 등)
    • 마이크로서비스 아키텍처에서 널리 사용
    • API 게이트웨이 및 보안 제품과 통합

  2. OpenID Connect 채택 현황

    • Google, Microsoft, Auth0, Okta 등 주요 ID 제공자 지원
    • B2C 및 B2B 인증에 점점 더 많이 사용됨
    • 엔터프라이즈 환경에서의 SSO 구현에 선호
    • 금융 서비스 및 의료 분야에서 이용 증가

  3. 최신 발전

    • OAuth 2.1: OAuth 2.0의 모범 사례를 통합한 간소화된 버전 개발 중
    • FAPI(Financial-grade API): 금융 API를 위한 OAuth 프로필
    • 디바이스 흐름: IoT 장치를 위한 인증 방식
    • 동적 클라이언트 등록: 클라이언트 애플리케이션 자동 등록

OAuth 2.0 vs. OpenID Connect 비교표

특성OAuth 2.0OpenID Connect
기본 정보
발표 연도2012년2014년
표준화 기관IETFOpenID Foundation
프로토콜 유형인가 프레임워크인증 레이어 (OAuth 2.0 기반)
주요 목적
주요 기능인가(Authorization)인증(Authentication) + 인가
사용자 정보 접근✓✓
사용자 인증미지정✓
신원 확인×✓
핵심 컴포넌트
액세스 토큰✓✓
리프레시 토큰✓✓
ID 토큰×✓
UserInfo 엔드포인트×✓
흐름 및 그랜트 타입
인가 코드✓✓
암시적✓지원 (보안상 권장하지 않음)
클라이언트 자격 증명✓✓
리소스 소유자 비밀번호✓지원 (권장하지 않음)
하이브리드 흐름×✓
토큰 특성
액세스 토큰 형식미지정 (불투명 토큰 일반적)미지정 (JWT 일반적)
ID 토큰×JWT 형식 필수
서명 검증선택적필수 (ID 토큰)
사용자 정보
표준화된 클레임×✓
프로필 정보서비스별 API표준화된 UserInfo
스코프서비스 정의표준화된 스코프 (openid, profile 등)
보안 특성
PKCE 지원✓✓
세션 관리×✓
클라이언트 등록서비스별 방식표준화된 방식
로그아웃미지정프런트/백 채널 로그아웃 표준화
구현 및 복잡성
구현 복잡성낮음-중간중간-높음
서버 측 검증간단함복잡함 (JWT 검증)
클라이언트 라이브러리다수증가 추세
주요 사용 사례
API 접근 위임✓✓✓✓✓
사용자 로그인✓✓✓✓
Single Sign-On×✓✓✓
리소스 서버 접근✓✓✓✓✓
채택 및 지원
주요 서비스 지원Google, Facebook, Twitter, GitHub 등Google, Microsoft, Auth0, Okta 등
모바일 앱 지원✓✓✓✓✓
SPA(Single Page App) 지원✓✓✓✓✓
서버 사이드 앱 지원✓✓✓✓✓✓

용어 정리

용어설명

참고 및 출처