웹 서비스 개발 – 웹 서비스 보안 – 0 – SSL/TLS 개념과 동작 원리

웹 서비스 개발 - 웹 서비스 보안 - 0 - SSL/TLS 개념과 동작 원리
웹 서비스 개발 – 웹 서비스 보안 – 0 – SSL/TLS 개념과 동작 원리

웹 서비스 개발 – OAuth 인증 – OAuth 보안과 베스트 프랙티스

안녕하세요 여러분! 😄
오늘은 OAuth 인증의 마지막 단계이자, 가장 중요한 부분!
바로 **보안(Security)**과 **베스트 프랙티스(Best Practices)**에 대해 알아보겠습니다.

“OAuth는 편리하지만 해킹되면 큰일 아닌가요?”
“Access Token이 탈취되면 어떻게 하죠?”
👉 맞습니다! 편리한 만큼 보안도 철저히 신경 써야 해요.

이번 글에서는 보안 위협 사례, 실무에서 지켜야 할 필수 규칙들,
그리고 실전에서 자주 놓치는 주의사항까지 꼼꼼히 알려드릴게요! 🛡️


1. OAuth에서 발생할 수 있는 보안 위협 🚨

✅ 1.1 Access Token 탈취

  • 악성 스크립트나 브라우저 저장소 노출로 토큰이 유출될 수 있어요.
  • 탈취한 토큰으로 사용자 데이터에 무단 접근 가능.

✅ 1.2 Redirect URI 조작

  • 공격자가 의도적으로 리디렉션 주소를 조작해 인가 코드를 가로챌 수 있어요.
  • 인증 후 피싱 사이트로 이동하게 만들 수도 있어요.

✅ 1.3 CSRF (Cross-Site Request Forgery)

  • 사용자가 로그인 상태일 때, 외부 사이트가 인가 요청을 유도하여 자동으로 인증을 시도하게 만듦.

✅ 1.4 Authorization Code Interception

  • 인가 코드가 네트워크 중간에서 탈취될 경우,
    인증되지 않은 클라이언트가 토큰을 요청할 수 있음.

2. 보안을 위한 핵심 베스트 프랙티스 🔒

✅ 2.1 Redirect URI는 정확하게 등록하기

  • OAuth 제공자 콘솔에서 정확히 일치하는 URI만 허용해야 해요.
  • 와일드카드(*)는 절대 사용 금지!

잘못된 예:

https://example.com/*

올바른 예:

https://example.com/oauth/callback

✅ 2.2 HTTPS는 기본 중의 기본

  • 토큰이나 인가 코드, 사용자 정보가 평문 HTTP로 전송되면…
    와이파이 카페에서도 해커가 중간에서 엿볼 수 있어요 😱
  • OAuth 요청, 응답, 토큰 교환 모두 HTTPS 필수!

✅ 2.3 Access Token은 HttpOnly 쿠키에 저장

  • 브라우저의 localStoragesessionStorage에 저장하면
    XSS 공격에 매우 취약합니다.
  • 대신 서버 측에서 HttpOnly + Secure 설정된 쿠키로 토큰을 저장하고 관리하세요.

✅ 2.4 상태(state) 파라미터 꼭 사용하기

  • CSRF 방지를 위해 인가 요청 시 고유한 state을 보내고,
    응답 시 받은 state 값과 비교하세요.
$_SESSION['oauth_state'] = bin2hex(random_bytes(16));
// 요청 시 state 포함
if ($_GET['state'] !== $_SESSION['oauth_state']) {
  die('CSRF 공격 의심!');
}

✅ 2.5 PKCE (Proof Key for Code Exchange) 사용하기

  • 모바일, SPA(싱글페이지 앱)에서는 클라이언트 시크릿이 없기 때문에,
    인가 코드 탈취 방지를 위해 PKCE를 반드시 적용해야 해요.
1. 클라이언트가 code_challenge 생성
2. 인가 요청 시 code_challenge 포함
3. 토큰 요청 시 code_verifier 포함
4. 서버에서 검증 후 토큰 발급

✅ 2.6 최소한의 Scope 요청

  • profile email contacts calendar drive photo… ← ❌
    사용자가 부담을 느낄 수 있어요!

  • 정말 필요한 항목만 요청하세요:

scope=openid email

✅ 2.7 Refresh Token은 더 강력하게 보호

  • 재로그인 없이 새 Access Token을 받을 수 있는 열쇠이기 때문에,
    Refresh Token은 서버 측에만 저장하고
    브라우저에서는 절대 노출하지 않도록 합니다.

✅ 2.8 Access Token 수명은 짧게, Refresh Token은 주기적으로 갱신

  • Access Token은 10~30분 내 만료되도록 설정하세요.
  • Refresh Token도 유효 기간을 설정하고, 주기적으로 재발급하세요.

3. 추가 보안 전략 💡

전략 설명
사용자 로그 모니터링 비정상 로그인/접속 시도 탐지
토큰 블랙리스트 로그아웃 시 토큰을 무효화
2FA(이중 인증) 병행 OAuth 이후, 민감 기능에 추가 인증 적용
토큰 암호화 JWT 등 사용 시 토큰 자체에 서명 또는 암호화

4. 서비스 제공자별 보안 권장사항

플랫폼 보안 권장
구글 OpenID Connect + PKCE + 짧은 수명 토큰
카카오 Redirect URI 정확 매칭 + 비즈앱 등록 필수
네이버 state 반드시 포함 + Secure 쿠키 권장
GitHub Accept 헤더 및 CSRF 보호 필수
페이스북 App Review 후 확정된 scope만 사용

5. OAuth 보안 실수 사례 ⚠️

실수 문제 발생
인가 코드 전달 후 유효성 미검증 중간 탈취 가능
토큰을 localStorage에 저장 XSS로 탈취 가능
리디렉션 주소에 토큰 포함 토큰이 브라우저 기록에 남음
토큰 유효성 검증 생략 만료된/조작된 토큰 수락 가능

6. 보안을 위한 체크리스트 ✅

체크 항목 확인 여부
HTTPS 통신인가요? ☑️
Redirect URI는 엄격히 제한했나요? ☑️
state 파라미터를 검증하나요? ☑️
PKCE를 사용하고 있나요? (SPA/모바일) ☑️
Access Token은 HttpOnly 쿠키인가요? ☑️
최소 Scope만 요청했나요? ☑️
로그아웃 시 토큰을 무효화하나요? ☑️
토큰 저장소는 안전한가요? ☑️

마무리하며 😊

OAuth 인증은 보안에 민감한 기술입니다.
편리함만을 추구하다 보면, 사용자 데이터가 위험에 노출될 수 있어요.
하지만 오늘 알려드린 보안 규칙과 베스트 프랙티스만 잘 지키신다면,
탄탄하고 안전한 인증 시스템을 운영하실 수 있습니다! 💪

다음 편에서는 OAuth와 **JWT(JSON Web Token)**를 결합해
어떻게 인증 시스템을 구성할 수 있는지 소개드릴게요.

궁금하신 점은 언제든지 댓글로 남겨주시고,
안전한 서비스 운영 되시길 바랍니다!
감사합니다 🙌

답글 남기기