OAuth와 OpenID Connect : OAuth의 개념, 필요성

오뜨 복습하기

 

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

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

- OAuth의 정의, 목적

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

---

OAuth2

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

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

 

 

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

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

클라이언트가 정보를 등록하면 백엔드에서 자체적으로 객체를 만들어 저장했음

 

• 사용자가 ID/PW를 입력함
  • 애플리케이션 서버에서 인증을 직접 처리
  • 사용자의 크리덴셜을 내부 DB에 저장함

 

문제점

• 서비스가 늘어날수록 사용자 비밀번호가 여러곳에 흩어져서 저장된다
• 외부 API(Google Calendar 등)를 쓰려면 그 서비스의 비밀번호까지 보관해야 할 수 있다
• 유출시 피해가 크고, 비밀번호 변경 동기화 또한 어려워진다

 

 

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

써~드 파티 API를 연동하면 그 써드파티의 정보까지 받아서 저장해야하는 참사가 벌어진다

• 일정 서비스가 Google Calendar API를 쓰려면, 사용자의 구글 비밀번호를 받아 저장해야하는 상황이 벌어진다
• 사용자가 구글 비밀번호를 바꾸면 해당 서비스에도 다시 알려줘야만 한다
• 다른 서비스가 내 써드 파티의 비밀번호를 가지고 있다는 사실 자체가 커다란 보안 리스크가 된다

 

 

3. OAuth2의 등장 : 비밀번호 대신 토큰으로 권한을 위임함

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

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

애플리케이션은 이 토큰으로 리소스(API)를 사용할 수 있다

OAuth2를 활용하면 토큰만 주고받기 때문에 크리덴셜을 저장하지 않고 API를 쓸 수 있다

 

핵심적인 변화

• 비밀번호는 절대 공유되지 않는다
• 토큰 + 범위(Scope)로 필요한 권한만 위임한다
• 관리해야할 크리덴셜의 수가 줄어들어서 보안성이 향상됨

---

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

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

• 우리 서비스에서 Google Drive, Calendar, Github, Slack 등의 API를 호출함
• 사용자가 해당 서비스에 로그인/동의함 -> Access Token 발급 -> 우리 서비스가 해당 API를 호출
• 비밀번호는 몰라도 되고, 허용된 Scope 내에서만 접근 가능함

 

 

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

• 구글로 로그인, 네이버로 로그인, GitHub으로 로그인 등 다양한 수단 제공 가능
• 회원가입/로그인이 간편해지고, 서비스는 자체 비밀번호 저장소를 최소화할 수 있음
• 선택 가이드 : 자사 계정 체계는 필요하지만, 편의성도 챙기고 싶다면 소셜 로그인을 보조 수단으로 제공

---

OAuth2가 중요한 이유

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

---

내 서비스에 맞는지에 대한 체크리스트

1. 서비스 요구사항 확인
   • 써드 파티 API(Google, Github, Facebook, OKTA 등) 연동이 필요한가?
   • 자체 로그인만으로 충분하지 않나?(OAuth2가 필요없는 경우)
2. 보안 고려
   • 비밀번호를 직접 수집하거나 저장하지 않고 OAuth2만으로 인증 가능한가?
   • HTTPS를 강제하여 토큰 탈취 위험을 줄였는가?
   • Access Token 저장소를 안전하게 설계했는가?(DB 암호화, Secure Cookie, Keychain 등)
3. 토큰 관리 정책
   • Access Token은 짧은 만료 시간으로 설정했나?
   • Refresh Token을 발급할 경우, 별도의 보호 장치를 마련했나?
   • 토큰 무효화 전략(블랙리스트, Redis 저장 등)을 마련했나?
4. Scope 설정
   • 최소 권한 원칙(Principle of Least Privilege)을 적용했나?
   • 실제로 필요한 API 권한만 요청하는가?(Gmail 전체 접근 X, 캘린더 읽기 전용만 O)
5. 사용자 경험
   • 소셜 로그인 버튼을 통해 직관적 UX를 제공하는가?
   • OAuth 로그인 실패시 적절한 에러 메시지를 제공하는가?
   • 기존 회원 계정과 소셜 로그인 계정을 어떻게 맵핑할지에 대한 정책이 정의되어 있는가?
6. 운영 및 모니터링
   • 토큰 발급 및 만료 이벤트를 로깅하고 있는가?
   • OAuth2 인증 실패율, 토큰 재발급 빈도 등을 모니터링할 수 있는가?

---

팁

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

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

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

* 토큰 수명 설계 : 만료시간은 짧게, 장기 사용은 별도 플로우로 마련하기

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

---

정리

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