Token Authentication vs. OpenID Connect

현대 웹과 애플리케이션의 보안 생태계에서 인증과 권한 부여는 필수적인 요소이다. 토큰 인증(Token Authentication)과 OpenID Connect(OIDC)는 모두 이 영역에서 중요한 역할을 하지만, 목적과 기능 면에서 상당한 차이가 있다.

토큰 인증(Token Authentication)

토큰 인증은 사용자의 자격 증명(주로 사용자 이름과 비밀번호)을 검증한 후, 서버가 발급한 토큰을 통해 이후의 요청에서 인증을 수행하는 방식이다.

기본 개념 및 작동 원리

토큰 인증의 핵심 아이디어는 사용자가 로그인하면 서버가 서명된 토큰을 발급하고, 이후 모든 요청에 이 토큰을 포함시켜 사용자를 식별하는 것이다. 가장 널리 사용되는 토큰 형식은 JWT(JSON Web Token)이다.

인증 흐름:
- 사용자가 자격 증명(username/password)을 서버에 제출합니다.
- 서버는 이를 검증하고 토큰을 생성합니다.
- 클라이언트는 토큰을 저장하고(로컬 스토리지, 쿠키 등) 이후 요청에 포함시킵니다.
- 서버는 토큰을 검증하여 사용자를 식별합니다.
토큰 구조(JWT 기준):
- 헤더(Header): 토큰 유형과 사용된 알고리즘
- 페이로드(Payload): 사용자 ID, 권한, 만료 시간 등의 클레임(claims)
- 서명(Signature): 토큰이 변조되지 않았음을 보장하는 서명

주요 특징

무상태(Stateless): 서버는 토큰 상태를 저장할 필요가 없다.
자체 포함적(Self-contained): 필요한 모든 정보가 토큰 내에 포함된다.
확장성: 서버 간 세션 공유 없이 수평적 확장이 가능하다.
구현 단순성: 기본적인 토큰 인증은 구현이 상대적으로 간단하다.
직접 인증: 주로 애플리케이션이 사용자를 직접 인증한다.

OpenID Connect (OIDC)

OpenID Connect는 OAuth 2.0 프로토콜 위에 구축된 ID 계층으로, 클라이언트가 사용자의 신원을 확인하고 기본적인 프로필 정보를 얻을 수 있게 하는 인증 프로토콜이다.

기본 개념 및 작동 원리

OpenID Connect는, OAuth 2.0의 기본 기능인 권한 부여(Authorization)에 인증(Authentication) 기능을 추가함으로써, 인증과 권한 부여를 모두 처리할 수 있는 완전한 프로토콜을 제공한다.

주요 구성 요소:
- OpenID Provider(OP): 사용자 인증을 수행하는 서버
- Relying Party(RP): 인증을 요청하는 클라이언트 애플리케이션
- ID 토큰: 사용자의 신원 정보를 포함하는 JWT
- UserInfo 엔드포인트: 추가 사용자 정보를 제공하는 API
인증 흐름(권한 부여 코드 흐름 기준):
- 클라이언트가 사용자를 OpenID Provider로 리디렉션한다.
- 사용자가 OP에 로그인하고 클라이언트에 대한 권한을 승인한다.
- OP는 권한 부여 코드와 함께 사용자를 클라이언트로 리디렉션한다.
- 클라이언트는 이 코드를 사용하여 OP로부터 ID 토큰과 접근 토큰을 받는다.
- ID 토큰은 사용자의 신원을 확인하는 데 사용된다.
- 필요 시 접근 토큰으로 UserInfo 엔드포인트에서 추가 정보를 조회한다.

주요 특징

표준화된 프로토콜: 잘 정의된 규칙과 흐름을 제공한다.
연합 인증(Federated Authentication): 여러 서비스에서 단일 ID를 사용할 수 있다.
다양한 인증 흐름: 다양한 클라이언트 유형에 맞는 여러 인증 흐름을 지원한다.
사용자 정보 표준화: 표준 클레임 세트로 사용자 정보를 제공한다.
위임된 인증: 신뢰할 수 있는 제3자(OP)가 인증을 처리한다.

토큰 인증 vs. OpenID Connect 비교

특성	토큰 인증	OpenID Connect
정의	토큰 기반 인증 메커니즘	OAuth 2.0 위에 구축된 인증 프로토콜
핵심 목적	애플리케이션 내 인증	서비스 간 인증 및 사용자 정보 공유
범위	주로 단일 애플리케이션/서비스	여러 애플리케이션/서비스 간
복잡성	낮음 - 중간	중간 - 높음
표준화	특정 표준 없음(JWT는 표준화됨)	OpenID Foundation에 의해 표준화됨
인증 주체	주로 애플리케이션 자체	신뢰할 수 있는 ID 제공자(Google, Facebook 등)
구성 요소	주로 토큰 생성 및 검증	인증 서버, 클라이언트, ID 토큰, UserInfo 엔드포인트
토큰 형태	다양함(JWT, 불투명 토큰 등)	JWT 형식의 ID 토큰
토큰 내용	구현에 따라 다양함	표준화된 클레임 세트(sub, iss, aud 등)
구현 난이도	낮음 ~ 중간	중간 ~ 높음
확장성	높음(무상태 특성)	중간(일부 상태 유지 가능)
보안 기능	기본적(구현에 따라 다름)	고급(세션 관리, 토큰 철회, ID 토큰 검증 등)
단일 로그인(SSO)	기본 지원 없음(별도 구현 필요)	기본 지원
사용자 정보	토큰에 직접 포함 또는 별도 조회	표준화된 UserInfo 엔드포인트
사용자 동의	일반적으로 필요 없음	사용자 동의 화면 포함
주요 사용 사례	API 인증, 자체 서비스 인증	SSO, 소셜 로그인, 엔터프라이즈 인증
통합 용이성	높음(단순함)	중간(표준화되었으나 복잡)
프라이버시 제어	제한적	사용자 동의 기반의 정보 공유
개발자 경험	직관적이고 구현이 간단함	복잡하나 표준화된 라이브러리 존재

장단점 분석

토큰 인증의 장단점

장점:

구현이 상대적으로 간단하다.
무상태 특성으로 서버 확장성이 좋다.
개발 오버헤드가 적다.
자유로운 토큰 설계가 가능하다.
마이크로서비스 아키텍처에 적합하다.

단점:

표준화된 접근 방식이 없어 구현이 다양할 수 있다.
보안 구현의 책임이 개발자에게 있다.
토큰 취소 메커니즘이 기본적으로 없다.
사용자 정보 관리에 대한 표준이 없다.
서비스 간 신뢰 설정이 복잡할 수 있다.

OpenID Connect의 장단점

장점:

표준화된 인증 프로토콜로 상호 운용성이 좋다.
다양한 인증 흐름을 지원하여 다양한 사용 사례에 적용 가능하다.
신뢰할 수 있는 제3자 인증을 통한 보안 강화가 가능하다.
사용자 정보에 대한 표준화된 접근 방식을 제공한다.
단일 로그인(SSO)을 기본적으로 지원한다.

단점:

구현 복잡성이 높다.
설정 및 통합에 더 많은 노력이 필요하다.
외부 의존성(ID 제공자)이 생긴다.
네트워크 요청이 증가할 수 있다.
단순한 인증 요구사항에는 과도할 수 있다.

사용 시나리오

토큰 인증이 적합한 경우
1. 단일 애플리케이션/서비스: 외부 서비스와의 통합이 필요 없는 독립적인 애플리케이션
2. API 인증: 단순한 API 접근 제어
3. 마이크로서비스 내부 통신: 내부 서비스 간 인증
4. 모바일 애플리케이션: 효율적인 API 통신이 필요한 모바일 앱
5. 리소스 제약 환경: 경량 인증이 필요한 IoT 기기 등
OpenID Connect가 적합한 경우
1. 소셜 로그인: “Google로 로그인”, “Facebook으로 로그인” 등의 기능 구현
2. 단일 로그인(SSO): 여러 애플리케이션에 걸친 단일 로그인 구현
3. 엔터프라이즈 환경: 다양한 애플리케이션과 서비스에 대한 중앙 집중식 인증
4. 사용자 정보 공유: 애플리케이션 간에 일관된 사용자 프로필 정보 공유
5. 고급 인증 요구 사항: 다단계 인증, 동적 클라이언트 등록, 세션 관리가 필요한 경우

통합 및 하이브리드 접근법

실제 개발 환경에서는 두 접근 방식을 조합하여 사용하는 경우가 많다:

OIDC로 인증 후 토큰 인증 사용:
- OIDC를 통해 사용자 인증 및 기본 정보 획득
- 자체 JWT 토큰 발급 및 내부 서비스 인증에 사용
내부/외부 서비스 분리:
- 내부 서비스에는 단순한 토큰 인증 사용
- 외부 서비스 통합에는 OIDC 사용
계층적 접근:
- 게이트웨이/경계 수준에서 OIDC 인증
- 내부 마이크로서비스 간에는 전파된 JWT 사용

보안 고려사항

토큰 인증 보안
1. 안전한 토큰 전송: HTTPS를 통한 통신
2. 적절한 토큰 수명: 짧은 만료 시간 설정
3. 안전한 토큰 저장: XSS 공격 방지를 위한 안전한 저장소 사용
4. 토큰 서명 검증: 모든 요청에서 서명 검증
5. 비밀 키 보호: 서명 키의 안전한 관리
6. 민감한 정보 제외: 토큰에 비밀 데이터 포함 자제
OpenID Connect 보안
1. 정확한 ID 토큰 검증: 발급자, 대상, 만료 시간, nonce 검증
2. 상태 파라미터 사용: CSRF 공격 방지
3. 클라이언트 인증: 클라이언트 시크릿 보호
4. 리디렉션 URI 검증: 등록된 URI로만 리디렉션
5. 적절한 범위 요청: 필요한 최소한의 권한만 요청
6. PKCE(Proof Key for Code Exchange) 사용: 모바일/SPA 애플리케이션의 보안 강화

심층 분석

개념적 차이

가장 근본적인 차이점은 토큰 인증이 인증 메커니즘인 반면, OpenID Connect는 인증 프로토콜이라는 점이다. 토큰 인증은 서버가 토큰을 생성하고 클라이언트가 이를 제시하는 방식을 설명하는 일반적인 접근 방식이다. 반면, OIDC는 인증을 처리하기 위한 구체적인 규칙, 엔드포인트, 메시지 형식 및 흐름을 정의하는 완전한 프로토콜이다.

토큰 인증 작동 방식 예시 (JWT 사용)

 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
// 1. 로그인 및 토큰 발급
app.post('/login', (req, res) => {
  const { username, password } = req.body;
  
  // 사용자 검증
  if (validateUser(username, password)) {
    // JWT 생성
    const token = jwt.sign(
      { userId: user.id, username: user.username },
      'your-secret-key',
      { expiresIn: '1h' }
    );
    
    return res.json({ token });
  }
  
  return res.status(401).json({ message: '인증 실패' });
});

// 2. 토큰 검증
function authenticateToken(req, res, next) {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];
  
  if (!token) return res.status(401).send('토큰 없음');
  
  jwt.verify(token, 'your-secret-key', (err, user) => {
    if (err) return res.status(403).send('토큰 무효');
    
    req.user = user;
    next();
  });
}

// 3. 보호된 리소스 접근
app.get('/protected', authenticateToken, (req, res) => {
  res.json({ message: '보호된 데이터', user: req.user });
});

OpenID Connect 작동 방식 예시

 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
63
64
65
66
67
68
// 1. 인증 시작
app.get('/login', (req, res) => {
  // 상태 및 nonce 생성 (보안)
  const state = crypto.randomBytes(16).toString('hex');
  const nonce = crypto.randomBytes(16).toString('hex');
  req.session.oidc_state = state;
  req.session.oidc_nonce = nonce;
  
  // OpenID Provider로 리디렉션
  const authUrl = `https://openid-provider.com/auth?` +
    `client_id=your-client-id&` +
    `redirect_uri=${encodeURIComponent('http://your-app.com/callback')}&` +
    `response_type=code&` +
    `scope=openid profile email&` +
    `state=${state}&` +
    `nonce=${nonce}`;
  
  res.redirect(authUrl);
});

// 2. 콜백 처리
app.get('/callback', async (req, res) => {
  const { code, state } = req.query;
  
  // 상태 검증
  if (state !== req.session.oidc_state) {
    return res.status(403).send('상태 불일치, CSRF 공격 가능성');
  }
  
  try {
    // 권한 부여 코드를 토큰으로 교환
    const tokenResponse = await axios.post('https://openid-provider.com/token', {
      grant_type: 'authorization_code',
      code,
      redirect_uri: 'http://your-app.com/callback',
      client_id: 'your-client-id',
      client_secret: 'your-client-secret'
    });
    
    const { id_token, access_token } = tokenResponse.data;
    
    // ID 토큰 검증
    const decodedToken = jwt.decode(id_token);
    
    // nonce 검증
    if (decodedToken.nonce !== req.session.oidc_nonce) {
      return res.status(403).send('nonce 불일치');
    }
    
    // 추가 검증 (발행자, 대상, 만료 시간 등)
    // ...
    
    // 사용자 정보 조회 (선택적)
    const userInfoResponse = await axios.get('https://openid-provider.com/userinfo', {
      headers: { 'Authorization': `Bearer ${access_token}` }
    });
    
    // 사용자 정보 저장 및 세션 설정
    req.session.user = {
      ...decodedToken,
      ...userInfoResponse.data
    };
    
    res.redirect('/dashboard');
  } catch (error) {
    res.status(500).send('인증 처리 중 오류 발생');
  }
});

용어 정리

용어	설명

Token Authentication vs. OpenID Connect