OAuth 2.0의 보안 이슈와 해결 방안: 안전한 인증 시스템 구축하기

 

 

 

OAuth 2.0에서 발생할 수 있는 보안 이슈

OAuth 2.0은 편리한 인증 및 인가 시스템을 제공하지만, 토큰 탈취와 공격 시나리오 에 노출될 수 있습니다. 올바른 보안 설정을 하지 않으면 민감한 사용자 정보 가 노출될 수 있으며, 특히 모바일 및 웹 애플리케이션 환경에서 보안이 중요한 문제가 됩니다.

 

---

 

1. 토큰 탈취 및 재사용 공격

 

1.1 토큰 탈취(Token Hijacking)

토큰 탈취 는 악의적인 사용자가 유효한 Access Token 또는 Refresh Token 을 탈취해 인증된 사용자의 권한으로 API에 접근 하는 공격입니다.

 

예시: 토큰 탈취 공격 흐름

1. 사용자가 로그인한 후 Access Token 을 부여받습니다.
2. 네트워크 공격자가 중간자 공격(MITM) 을 통해 해당 토큰을 가로챕니다.
3. 공격자는 탈취한 토큰으로 API에 접근합니다.

해결 방법:
- HTTPS를 사용 해 모든 통신을 암호화합니다.
- 토큰의 유효 기간 을 짧게 설정하고, 주기적으로 갱신합니다.

 

---

 

2. PKCE(Proof Key for Code Exchange)의 중요성

 

PKCE란 무엇인가?

PKCE(Proof Key for Code Exchange) 는 공개 클라이언트 (예: 모바일 앱)에서 Authorization Code Grant 를 사용할 때 코드 탈취 공격을 방지 하는 보안 메커니즘입니다.

PKCE 작동 원리

1. 클라이언트가 코드 챌린지(Code Challenge) 를 생성해 권한 부여 요청에 포함합니다.
2. 권한 부여 서버는 클라이언트로부터 Authorization Code 를 받을 때 코드 챌린지 와 비교합니다.
3. 일치할 경우에만 Access Token 을 발급합니다.

 

PKCE 적용 예제

import hashlib
import base64

def generate_code_challenge(code_verifier):
    challenge = hashlib.sha256(code_verifier.encode()).digest()
    return base64.urlsafe_b64encode(challenge).rstrip(b'=').decode()

code_verifier = "random_string_for_verification"
code_challenge = generate_code_challenge(code_verifier)
print(f"Code Challenge: {code_challenge}")

 

 

OAuth 2.0에서 발생할 수 있는 보안 이슈

OAuth 2.0은 편리한 인증 및 인가 시스템을 제공하지만, 토큰 탈취와 공격 시나리오 에 노출될 수 있습니다. 올바른 보안 설정을 하지 않으면 민감한 사용자 정보 가 노출될 수 있으며, 특히 모바일 및 웹 애플리케이션 환경에서 보안이 중요한 문제가 됩니다.

 

---

 

1. 토큰 탈취 및 재사용 공격

 

1.1 토큰 탈취(Token Hijacking)

토큰 탈취 는 악의적인 사용자가 유효한 Access Token 또는 Refresh Token 을 탈취해 인증된 사용자의 권한으로 API에 접근 하는 공격입니다.

 

예시: 토큰 탈취 공격 흐름

1. 사용자가 로그인한 후 Access Token 을 부여받습니다.
2. 네트워크 공격자가 중간자 공격(MITM) 을 통해 해당 토큰을 가로챕니다.
3. 공격자는 탈취한 토큰으로 API에 접근합니다.

해결 방법:
- HTTPS를 사용 해 모든 통신을 암호화합니다.
- 토큰의 유효 기간 을 짧게 설정하고, 주기적으로 갱신합니다.

 

---

 

2. PKCE(Proof Key for Code Exchange)의 중요성

 

PKCE란 무엇인가?

PKCE(Proof Key for Code Exchange) 는 공개 클라이언트 (예: 모바일 앱)에서 Authorization Code Grant 를 사용할 때 코드 탈취 공격을 방지 하는 보안 메커니즘입니다.

PKCE 작동 원리

1. 클라이언트가 코드 챌린지(Code Challenge) 를 생성해 권한 부여 요청에 포함합니다.
2. 권한 부여 서버는 클라이언트로부터 Authorization Code 를 받을 때 코드 챌린지 와 비교합니다.
3. 일치할 경우에만 Access Token 을 발급합니다.

 

PKCE 적용 예제

import hashlib
import base64

def generate_code_challenge(code_verifier):
    challenge = hashlib.sha256(code_verifier.encode()).digest()
    return base64.urlsafe_b64encode(challenge).rstrip(b'=').decode()

code_verifier = "random_string_for_verification"
code_challenge = generate_code_challenge(code_verifier)
print(f"Code Challenge: {code_challenge}")

설명:
- 코드 챌린지 는 클라이언트와 서버 간의 일회성 검증 을 가능하게 하여 코드 탈취 공격 을 방지합니다.

 

---

 

3. OAuth 공격 시나리오와 대응 방법

공격 유형	설명	대응 방법
중간자 공격(MITM)	네트워크 상에서 토큰을 가로채는 공격	HTTPS 사용 으로 통신 암호화
Redirect URI 조작	공격자가 Redirect URI를 위조해 토큰을 탈취	엄격한 URI 검증 과 화이트리스트 적용
CSRF 공격	사용자가 의도하지 않은 요청을 서버에 전달	상태 토큰(State Token) 을 사용해 CSRF 방지
토큰 재사용 공격	탈취한 토큰을 반복 사용	짧은 유효 시간 과 블랙리스트 사용

---

 

4. CSRF(State Token)와 토큰 무효화 전략

 

CSRF(State Token) 사용

OAuth 2.0에서는 상태 토큰(State Token) 을 사용해 CSRF 공격 을 방지합니다. 상태 토큰은 클라이언트와 서버 간 세션의 무결성을 검증 합니다.

 

CSRF 방지 예제 코드

import os
from flask import Flask, session, redirect, request

app = Flask(__name__)
app.secret_key = os.urandom(24)

@app.route('/login')
def login():
    session['state'] = os.urandom(24).hex()
    auth_url = f"https://accounts.google.com/o/oauth2/auth?response_type=code&state={session['state']}"
    return redirect(auth_url)

@app.route('/callback')
def callback():
    if request.args.get('state') != session['state']:
        return "CSRF 공격 감지", 400
    return "로그인 성공"

if __name__ == '__main__':
    app.run(debug=True)

설명:
- 상태 토큰 을 세션에 저장하고, 콜백 시 검증해 CSRF 공격 을 방지합니다.

토큰 무효화 전략

• 토큰 블랙리스트 를 사용해 만료된 토큰의 재사용을 방지합니다.
• 사용자가 로그아웃할 때 모든 토큰을 무효화 합니다.

 

---

 

5. 최신 보안 트렌드와 OAuth 2.1

• OAuth 2.1 은 Implicit Grant 방식을 제거해 토큰 노출 위험 을 줄였습니다.
• 모든 클라이언트에서 PKCE 사용이 권장 되며, 특히 모바일 환경에서는 필수적입니다.
• Refresh Token의 무기한 사용을 지양 하고, 토큰 만료 시 자동 재발급을 권장합니다.

 

---

 

FAQ

Q1. OAuth 2.0에서 PKCE는 왜 중요한가요?
A1. PKCE는 코드 탈취 공격 을 방지하는 데 중요한 역할을 합니다. 특히 모바일 앱 에서는 필수로 사용해야 합니다.

Q2. 토큰 유효 기간은 어떻게 설정하는 것이 좋나요?
A2. Access Token 은 짧게(예: 10~30분), Refresh Token 은 비교적 길게 설정해 보안과 편의성 을 균형 있게 유지합니다.

Q3. Redirect URI를 안전하게 관리하려면 어떻게 해야 하나요?
A3. 화이트리스트 방식 으로 승인된 URI만 허용하고, 임의의 URI로 리디렉션되지 않도록 합니다.

Q4. Refresh Token을 안전하게 저장하는 방법은 무엇인가요?
A4. HTTPS를 통해 전송 하고, 서버 측에 암호화된 상태로 저장 합니다.

Q5. OAuth 2.1에서는 어떤 변화가 있나요?
A5. OAuth 2.1에서는 Implicit Grant 제거 , PKCE 필수화 , 토큰 만료 시 자동 갱신 권장 과 같은 보안 개선이 이루어졌습니다.

 

---