OAuth : OAuth?

오뜨 (어려움)

 

 - OAuth가 등장한 배경, 필요성

 - 접근 권한 위임이라는 개념을 사례와 연결해서 이해

 - OAuth의 정의, 목적

 - OAuth를 사용하는 대표적 서비스 사례

 

---

 

OAuth 2

웹/앱의 소셜 로그인과 써드 파티 API 연동은 대부분 OAuth 2를 바탕으로 구현된다

핵심은 "비밀번호는 절대 주지 말고, 필요한 범위만 토큰으로 위임하자"

 

1. 전통적 인증 처리 방식, 한계

전통적 애플리케이션은 자체 회원을 만들고 ID, Password(크리덴셜)을 직접 저장했음

전통적 인증 처리 방식

 

클라이언트가 회원 인증 정보를 등록 - > 백엔드(애플리케이션 서버)에서 정보를 받음 - > 인증도 직접 처리함

- > 크리덴셜 저장소(내부 DB)를 따로 만들어서 저장한 뒤 관리

 

문제점

 - 서비스가 늘어갈수록 사용자의 비밀번호가 여러 곳에 흩어져서 저장될 수 있음

 - 외부 API(Google 캘린더 같은것들..)를 쓰려면 그 서비스의 비밀번호까지 보관해야 할 수 있음

 - 유출되면 피해가 크고, 비밀번호 변경 동기화도 어려움

 

 

2. 써드 파티 API 연동시 발생하는 추가 문제

위 인증 처리 방식에서 외부 API를 사용하는게 추가됨

 

 - 일정 서비스가 Google 캘린더 API를 쓰려면, 사용자의 구글 비밀번호를 받아서 저장해야하는 상황이 생김

 - 사용자가 구글 비밀번호를 바꾸면 서비스에도 다시 알려줘야함, 매우 귀찮고 번거로움

 - 애초에 다른 서비스가 내 비밀번호를 가지고 있다는 사실 자체가 큰 보안 리스크임

 

3. OAuth2 등장 - 비밀번호 대신 토큰으로 권한 위임

OAuth2는 사용자의 비밀번호를 제3자 앱이 알 필요가 없도록 만들었음

신뢰 가능한 인증 서버(Google 등..)가 인증을 담당하고, 애플리케이션(클라이언트)에게 Access Token을 발급함.

애플리케이션은 이 토큰으로 리소스(API)를 사용함

OAuth2를 활용해서 인증서버가 인증해주고, 애플리케이션에게 토큰 전송

 

핵심적인 차이점

 - 비밀번호는 절대 공유되지 않음

 - 토큰 + 범위(Scope)로 필요한 권한만 위임함

 - 관리해야할 크리덴셜의 수가 줄어서 보안성이 향상됨

 

 

---

 

 

OAuth2를 사용하는 애플리케이션 유형

1. 써드파티 API를 직접 사용하는 서비스

 - 가령, 우리 서비스가 Google Drive, Calendar, GitHub, Slack 등의 API들을 호출한다고 하자

 - 사용자가 해당 서비스에 로그인/동의 - > API쪽에서 Access Token 발급 - > 우리 서비스가 API 호출하는 흐름

 - 비밀번호는 몰라도 되고, 허용된 Scope 내에서만 접근할 수 있게 됨

 

2. 로그인 수단으로 제공(소셜 로그인)

 - 구글로 로그인, 네이버로 로그인, GitHub로 로그인, 페이스북으로 로그인 등 이런걸 클릭한다고 하자

 - 회원가입/로그인이 간편해지고, 서비스는 자체 비밀번호 저장을 하지 않아서 저장소를 최소화 할 수 있음

 - 선택 가이드 : 자사 계정 체계는 필요하되, 편의성을 중시한다면 소셜 로그인을 보조 수단으로 제공해줄 수 있음

 

 

---

 

 

OAuth2, 왜 중요함? - 보안, 편의, 확장성

관점	전통적 방식	OAuth2 방식	의미
비밀번호 처리	서비스가 직접 저장	저장하지 않음	유출면적 감소
권한 범위	계정 전체	Scope 단위 최소 권한	과도한 권한 방지
연결성	서비스마다 계정 필요	하나의 계정으로 다수의 서비스 연동	UX 향상
유지관리	변경 동기화 필요	토큰 재발급/만료 관리	운영이 단순해짐
보안 사고	치명적임(비밀번호 유출)	토큰 만료/회수로 피해 축소	리스크 완화

 

 

---

 

 

체크리스트 - 우리 서비스에 맞는가?

1. 서비스의 요구사항 확인

 - 써드파티 API(Google, GitHub, Facebook 등..) 연동이 필요한가?

 - 자체 로그인만으로 충분하지 않음??

 

2. 보안 고려

 - 비밀번호를 직접 수집하거나 저장하지 않고 OAuth만으로 인증 가능한가?

 - HTTPS를 강제하여 토큰 탈취 위험을 줄였는가?

 - Access Token 저장소를 안전하게 설계했는가? (DB 암호화, Security Cookie, KeyChain 등..)

 

3. 토큰 관리 정책

 - Access Token의 만료시간을 짧게 설정했는가?

 - Refresh Token을 발급할경우 별도의 보호 장치를 마련해뒀는가?

 - 토큰 무효화 전략(블랙리스트, Redis 저장 등..)을 마련했는가??

 

4. Scope 설정

 - 최소 권한 원칙(Principle of Least Privilege)을 적용했는가?

 - 실제로 필요한 API 권한만을 요청했는가? (캘린더 읽기 전용뿐만 아니라 Google 전체 접근 형태..)

 

5. 사용자 경험

 - 소셜 로그인 버튼을 통해 직관적 UX를 제공하는가?

 - OAuth 로그인 실패시 적절한 에러 메시지를 제공하는가?

 - 기존 회원 계정과 소셜 로그인 계정을 어떻게 맵핑할지 정책이 정의되어 있는가?

 

6. 운영 및 모니터링

 - 토큰 발급 및 만료 이벤트를 로깅하고 있는가?

 - OAuth 인증 실패율, 토큰 재발급 빈도 등을 모니터링할 수 있는가?

 

---

 

팁

 - Scope 최소화 : 처음에는 읽기 전용(read)만 요청하고, 정말 필요할 때 쓰기(write) 범위를 추가로 요청하기

 - 동의 화면은 투명하게 하기 : 왜, 무엇에 접근하는지 쉽게 적고 예/아니오 선택을 명확하게 제공하기

 - 토큰 보관은 안전하게 : 브라우저, 모바일에서 저장소 선택(LocalStorage, Keychain 등???)에 각별히 주의하기

 - 토큰 수명 설계 : 만료시간은 짧게, 장기 사용은 별도 플로우를 쓰기(RefreshToken의 사용 등)

 - 감사 로그 : 누가, 언제, 어떤 범위를 승인/철회했는지 감사 가능하도록 남기기

 

 

뭔소린지 아직 잘 모르니까 정리를 통해 복습하기

항목	핵심 요약
문제의식	비밀번호 공유/중복 저장은 보안, 운영 모두에 취약함
해법	OAuth2 : 비밀번호 대신 토큰, 범위(Scope) 기반 권한 위임
적용 유형	써드 파티 API 직접 사용, 소셜 로그인
기대 효과	보안성 up, 편의성 up, 확장성 up
주의점	Scope / 동의 UX / 토큰 보관, 만료 설계를 반드시 함께 고려하기