OAuth와 OpenID Connect : OAuth 주체와 설정

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

- Client ID와 Client Secret의 의미, 역할 구분하기

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

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

- 실제 사례와 연결하여 OAuth 알기

---

OAuth2 인증 컴포넌트들의 역할

OAuth2는 단순 "소셜 로그인"을 구현하는 기술이 아니라, 보호된 자원(Resource)에 안전하게 접근하기 위한 표준 프로토콜임

이를 위해 네 가지 핵심 컴포넌트가 존재한다

• Resource Owner(user)
• Client
• Resource Server
• Authorization Server

 

1. Resource Owner(User)

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

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

B1uffer라는 사용자가 Google 계쩡으로 Google Calendar에 접근한다면, B1uffer가 Resource Owner가 됨

 

* Resource Owner는 서비스 사용자(User)를 의미한다

 

 

 

2. Client

Resource Owner를 대신하여 Resource에 접근하는 애플리케이션임

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

B1uffer가 일정 관리 앱(A)을 사용하고, 이 앱이 Google Calendar API에 접근한다면 앱 A를 Client라고 함

 

* 서비스 제공자가 서비스를 이용하고자 하는 쪽이 Client이다, Client와 Server의 구분을 헷갈리지 말자

항상 서비스를 제공하는 쪽을 Server라고 기준잡으면 된다

 

 

 

3. Resource Server

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

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

Google Photo API 서버는 Resource Server임

 

* Resource Server는 실제 데이터가 존재하는 곳이다

 

 

 

4. Authorization Server

Resource Owner의 인증을 처리하고, Client에게 Access Token을 발급하는 서버임

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

Google의 로그인 서버가 Authorization Server가 된다

 

* Authorization Server는 Access Token 발급자이다

---

OAuth2 컴포넌트간 상호 작용

OAuth2의 핵심은 Client가 Resource Owner의 대리인 역할을 한다는 것임

Resource Owner가 Client에게 인증 요청만 하면 알아서 해주는 형태

 

1. Resource Owner는 Client(앱)에게 로그인 요청을 한다
2. Client는 자체 로그인 창이 아닌, 써드 파티 서비스의 로그인 페이지로 리다이렉트한다
3. Resource Owner는 Authorization Server에서 직접 로그인한다
4. 로그인 성공시 Authorization Server는 Client에게 Access Token을 발급해준다(Resource Owner에게 주는게 아님)
5. Client는 발급받은 Access Token을 이용해 Resource Server에게 요청한다
6. Resource Server는 Access Token을 검증한 뒤, 요청한 자원을 Client에게 반환해준다

가령 Google을 예로 들 때

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

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

---

권한 범위(Scope) 설정

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

"어떤 자원(Resource)에 대해, 어느 정도까지 접근을 허용할 것인가"를 지정하는 제한 장치임

 

1. Scope의 의미

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

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

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

 

 

 

2. Scope 예시

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

 

Scope는 보통 리소스 단위 + 접근 수준을 조합해서 설계한다

 

 

 

3. 사용자 경험과 보안

사용자는 Scope 동의 화면을 보고 애플리케이션이 요청하는 권한을 직접 확인할 수 있다

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

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

 

 

 

4. Scope가 중요한 이유

• 보안 사고 위험 감소
  • 단순히 "전체 계정 접근"만 허용했다면, 캘린더를 조회하려는 앱이 사용자의 이메일, 연락처까지 무단으로 읽을 수 있다
  • Scope는 이런 사고를 방지하게끔 한다
• 사용자의 신뢰 확보
  • 사용자가 동의 화면을 통해 "앱이 내 이메일 주소만 가져가는군"을 확인할 수 있다
  • 불필요한 권한을 요구하는 앱은 거부당할 확률이 높다
• 실패 사례
  • 어떤 앱이 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)했는가?

---

정리

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

 

* Authorization Server와 Resource Server를 구분해야한다