OAuth : 주체와 설정

오뜨의 주체, 오뜨를 설정하는 법..이라..

 

 - OAuth의 주요 주체(유저, 클라이언트, 인가 서버, 리소스 서버) 이해

 - Client ID와 Client Secret의 의미와 역할 명확하게 구분

 - Scope 설정이 가지는 중요성, 실무적 활용 방법

 - OAuth 설정이 애플리케이션 보안과 사용자 경험에 어떤 영향을 미치는가?

 - 실제 서비스 사례로 OAuth 체감하기

 

---

 

OAuth2 인증 컴포넌트들의 역할

OAuth2는 소셜 로그인'만' 구현하는 기술..이 맞는것 같지만 아니며,

보호된 자원(Resource)에 안전하게 접근하기 위한 표준 프로토콜임.. 4가지 핵심 컴포넌트가 있다고 한다

 

1. Resource Owner(User)

 - Resource(자원)의 실제 소유자

 - 사용자는 자신의 계정 정보를 직접 관리하고 있으며, OAuth2 프로세스에서 최종 결정권을 가진 주체이다.

소셜 로그인 할 때 확인을 누가 누르는가?

 - 핵심 : Resource Owner는 서비스 사용자(User)를 의미함

 

2. Client

 - Resource Owner를 대신하여 Resource에 접근하는 애플리케이션임. 절대로 사용자인 "너"가 아니다..

 - 서버, 웹, 모바일 등 다양한 형태가 될 수 있음

내가 특정 앱을 사용하여, 이 앱이 특정 API에 접근한다면, '앱'이 Client가 된다

 - 핵심 : 서비스 제공자(x), 서비스를 이용하고자 하는 쪽인데, User가 아닌 앱이 Client임

 

3. Resource Server

 - 보호된 자원을 실제로 저장하고 있는 서버

 - Client의 요청을 Access Token으로 검증하고, 올바르다면 자원을 반환함

Google의 Google Calendar API 서버는 Resource Server라고 볼 수 있다

 - 핵심 : 실제, 진짜 데이터가 존재하는 곳이 Resource Server임

 

4. Authorization Server

 - Resource Owner의 인증을 처리하고, Client에게 Access Token을 발급하는 서버, Resource Server랑 다르다

 - OAuth2에서 가장 중요한 역할을 맡고 있으며, 자격 증명의 신뢰성을 보장한다고 함

Google 로그인 서버가 Authorization Server라고 함. 이건 앱이 아니고 Google Calendar API를 다루는 곳이잖아!

 - Authorization Server는 Access Token의 '발급자'이다

 

---

 

OAuth2 컴포넌트간 상호작용

OAuth2의 핵심은 Client가 Resource Owner의 대리인 역할을 한다는 것이라고 함

OAuth2 컴포넌트간 상호작용을 통한 인증 처리 흐름

 

1. Resource Owner가 Client에게 로그인 요청을 함

2. Client는 자기들이 가진 자체 로그인 창이 아니라, 써드 파티 서비스의 로그인 페이지로 리다이렉트함

3. Resource Owner는 Authorization Server에서 직접 로그인함

4. 로그인이 성공하면 Authorization Server는 Client에게 Access Token을 발급해줌.

*** Resource Owner에게 직접 Access Token을 주는게 아니라, Client에게 발급해준다

5. Client는 발급받은 Access Token을 이용해서 Resource Server에 요청함 (Authorization Server에 요청하지 않음)

6. Resource Server는 Access Token을 검증한 뒤, 요청한 자원을 Client에게 반환해준다. (Resource Server가 검증한다)

 

---

 

예 - 시(Google)

예시 : Google 서비스를 이용하는 사용자의 대리인 역할을 하는 일정 관리 앱

 

 - Resource Owner : 사용자

 - Client : 일정 관리 애플리케이션, Resource Owner가 OAuth2 인증 요청을 하는 초록색 박스

 - Authorization Server : Google 로그인 서버, (2) Google 로그인 페이지에서 (3) 인증해주는 서버

 - Resource Server : Google Calendar API 서버, (5)와 (6)에서 일정관리 앱과 요청하고 응답하는 서버

 

일정관리 애플리케이션은 Google 네트워크 안의 자원에 접근하기 위해서 Client로 동작하며,

Google의 서버들이 Authorization Server와 Resource Server의 역할을 나누어 수행한다.

웹 애플리케이션 서버는 Authorization Server와 Resource Server를 가지고 있지 않다고 생각하면 된다.........

 

---

 

권한 범위(Scope) 설정

OAuth에서 Scope(스코프)는 클라이언트(Client)가 유저(Resource Owner)를 대신해서 접근할 수 있는 권한의 범위를 정의함

"어떤 자원(Resource)에 대해 어느 정도까지 접근을 허용할 것인가??" 를 지정하는 제한 장치라고 볼 수 있다

 

1. Scope?

 - Scope는 사용자의 데이터 보호와 최소 권한 원칙(Principle of Least Privilege)을 적용하기 위한 핵심 매커니즘임

 - 클라이언트 애플리케이션은 Scope를 요청(Request)하고, 사용자는 동의 화면에서 이를 확인한 뒤 허용해준다.

 - 따라서 Scope는 사용자 동의와 보안 경계를 동시에 담당한다고 보면 된다...

 

2. 예시

Scope 값	설명
email	사용자의 이메일 주소 조회
profile	기본 프로필 정보 조회(이름, 사진, 등등..)
calendar.readonly	캘린더 읽기 전용 접근하기
calendar	캘린더 읽기, 쓰기 모두 가능
contacts.read	연락처 읽기 권한
contacts.write	연락처 추가, 수정, 삭제 권한

 

Scope는 일반적으로 리소스 단위 + 접근 수준을 조합해서 설계한다.. (calendar.readonly, calendar.write, ...)

 

3. 사용자 경험과 보안

 - 사용자는 Scope 동의 화면을 보고 애플리케이션이 요청하는 권한을 직접 확인할 수 있다. 선택도 할 수 있는게 있었음..

 - 클라이언트는 꼭 필요한 Scope만 요청해야 하며, 불필요하게 많은 권한을 요구하면 사용자의 불신을 초래할 수 있다..

 - 보안 측면에서 Scope는 데이터 유출 범위를 제한하는 중요한 장치가 된다..

 

 

4. Scope는 왜 중요한가??

1) 보안 사고 위험 감소

 - 만약 단순히 "전체 계정 접근"만 허용했다면, 캘린더를 조회하려는 앱이 사용자의 이메일, 연락처까지 무단으로 읽을 수 있음

 - 이걸 예방하기 위해서 Scope를 설정하는 것이다..

 

2) 사용자의 신뢰 확보

 - 사용자가 동의 화면을 통해서 "이놈의 앱이 내 이메일 주소만 가져가는군?"을 확인할 수 있다

 - 불필요한 권한까지 요구하는 앱들은 사용하지 않겠지?

 

3) 실패 사례

 - 어떤 앱이 contacts.read만 필요했는데 contacts.write까지 요청함 - > 사용자는 "내 연락처를 추가, 수정, 삭제하려고 해??" 라는 생각을 하게 됨 - > 동의하지 않고 다른 앱을 사용하러감, 나도 그러니까!

 

 

5. Scope 설계 원칙

 - 최소 권한 원칙 : 앱이 동작하는 데 꼭 필요한 권한만 요청하기

 - 리소스 단위로 구분하기 : 캘린더, 이메일, 연락처 등 리소스별로 Scope를 나누기

 - 읽기, 쓰기 분리 : read와 write를 나누어서 세분화하기

 - 사용자에게 직관적인 이름 부여하기 : Scope 값을 사용자가 쉽게 이해할 수 있도록 직관적으로 쓰기

 

---

 

체크리스트

 - 서비스에서 어떤 자원을 외부 API로부터 가져올지 정의했는가?

 - Resource Owner, Client, Authorization Server, Resource Server가 각각 무엇인지 명확하게 식별했는가?

 - Access Token의 발급 및 검증 과정을 누가 담당할지 설계했는가?

 - Client가 저장하지 말아야 할 민감한 정보들(비밀번호 등등..)을 분리했는가?

 - Resource Server에 대한 접근 범위를 최소화(Least privilege) 했는가?

 

---

 

OAuth 주체, 설정에 대한 정리

컴포넌트	역할	예시
Resource Owner	자원의 실제 소유자(나, 너)	사용자(B1uffer)
Client	자원 접근을 대리하는 애플리케이션	일정 관리 앱
Authorization Server	인증 후 Access Token 발급	Google 로그인 서버
Resource Server	자원이 실제로 존재하는 서버	Google Calendar API