OAuth란 무엇인가?

OAuth란 무엇인가?

✅ 주요 특징:

• 비밀번호를 직접 전달하지 않고도 사용자 권한을 위임 가능
• Access Token을 통해 자원 접근 제어
• 인증(Authentication)과 권한 위임(Authorization)을 분리

OAuth 1.0과 2.0의 차이점

항목	OAuth 1.0a	OAuth 2.0
인증 방식	서명 기반 (HMAC-SHA1 등)	토큰 기반 (Bearer Token)
보안 처리	메시지에 서명 포함 → 중간자 공격 방지	HTTPS 기반 전송 보안에 의존
토큰 형식	자체 구조 없음 (랜덤 문자열)	JWT 등 구조화된 토큰 가능
복잡도	서명 알고리즘 처리로 구현 복잡	상대적으로 간단하고 유연함
클라이언트 유형 구분	없음	Public / Confidential 클라이언트 구분 도입

📌 OAuth 2.0은 더 유연하고 다양한 사용 시나리오(웹, 모바일, API 등)를 고려한 현대적인 인증 프로토콜입니다. 현재는 거의 대부분 OAuth 2.0이 표준으로 사용됩니다.

---

왜 OAuth가 필요한가?

시나리오	문제	OAuth로 해결
소셜 로그인 (예: 구글 계정으로 로그인)	타 사이트에 비밀번호 노출 위험	토큰 기반 위임으로 보안 강화
외부 시스템이 내 API 호출	API Key만으로는 세분화된 권한 제어 어려움	토큰 + Scope 기반 세분화
토큰 만료/갱신 필요	사용자 불편 / 인증 재요구	Refresh Token으로 사용자 경험 보장

---

주요 용어 정리

용어	설명
Resource Owner	리소스를 소유한 사용자
Client	리소스를 요청하는 제3자 앱 (예: 내 서비스)
Authorization Server	인증을 담당하는 서버 (토큰 발급 담당)
Resource Server	보호된 리소스를 제공하는 서버 (토큰 검증)
Access Token	인증이 완료된 후 발급되는 자원 접근용 토큰
Refresh Token	Access Token이 만료되었을 때 재발급 요청용 토큰
Scope	Access Token이 접근 가능한 자원의 범위를 지정하는 값

---

OAuth 2.0 인증 흐름 (Authorization Code Flow)

📌 이 흐름은 사용자가 브라우저에서 로그인하는 구조로, 보안상 가장 권장되는 방식입니다.

---

Scope의 활용

예시 Scope	설명
profile	사용자 이름, 이메일 등의 기본 프로필 정보 조회 권한
email	이메일 주소에 대한 접근 권한
read:posts	게시글 읽기 권한 (리드 전용)
write:posts	게시글 작성/수정 권한 (쓰기 권한 필요)

✅ Scope를 세분화하면 리소스별 접근 제어를 정밀하게 설정할 수 있으며, 사용자로부터 명확한 동의를 받는 UX도 가능해집니다.

---

Access Token과 Refresh Token 저장 및 관리 전략

• Access Token은 만료시간 짧게 (5~30분)
• Refresh Token은 HttpOnly 쿠키로 보관
• 만료 시 자동 재요청 (silent refresh)

---

백엔드를 통한 안전한 인증 구조

서버 투 서버(Server-to-Server) 방식이 안전한 이유

항목	이유
민감 정보 보호	client_secret, refresh_token과 같은 민감한 값은 서버에만 보관하여 노출 방지
토큰 재발급 처리	Access Token 만료 시 자동 갱신 처리를 서버에서 제어 가능 (silent refresh)
인증 후 유저 등록 처리	유저 정보 수신 후 DB 저장, 권한 부여, 마케팅 수신 동의 등 추가 처리 삽입 가능
세션 관리 통합	JWT 또는 세션 방식으로 통합된 인증 상태 관리 가능 (로그아웃, 강제 만료 등)
보안 정책 적용	WAF, Rate-limiting, 로그 기록, IP 제한 등 서버 측 보안 전략을 적용 가능
공통 로직 통합	다양한 OAuth Provider에 대한 인증 흐름을 하나의 인터페이스로 정리 가능 (Google, Kakao 등)
네트워크 구조상 이점	서버 내부 통신은 TLS 인증된 안전한 채널을 이용하므로 중간자 공격 방지에 유리

💡 실전에서는 보통 프론트엔드에서 로그인 버튼 클릭 → 백엔드에서 OAuth 인증 요청 생성 → 인증 완료 후 토큰 수신 및 유저 등록까지 한 번에 처리하는 구조를 사용합니다.

프론트-백엔드-OAuth 연동 흐름

---

실전 노하우 모음

주제	실무 팁
토큰 저장	Access/Refresh Token은 모두 서버에 저장하고 관리하는 구조 권장 프론트엔드에서는 토큰을 직접 보관하지 않으며, 인증 상태는 서버가 책임짐
토큰 갱신	Access Token 만료 시 백엔드에서 자동 갱신 처리 (silent refresh) Refresh Token은 서버 내 안전한 저장소(예: DB 또는 인메모리)에 보관
로그인 연동	최초 로그인 시 OAuth 프로필 기반 유저 테이블 생성 or 매핑 필요
상태 관리	인증 상태는 서버 세션 혹은 자체 JWT 기반으로 통합 관리 프론트는 단순히 인증 유무만 판단 (예: /me API 응답 기반)
로그아웃 처리	Access/Refresh 모두 서버에서 무효화 처리, 세션 삭제 및 쿠키 제거 포함

✅ 서버-투-서버 구조에서는 브라우저의 LocalStorage 또는 SessionStorage를 사용하지 않으며,
모든 민감한 인증 정보는 서버가 책임지고 관리해야 합니다.

---

마무리