1. Background
OAuth (Open Authorization) 이란 Web Authorization Protocol (oauth) 에서 산업 표준(industrial-standard)으로 개발된 것으로, Client 개발자에게 인증 FLow를 간편하게 제공합니다.
더 쉽게 말하자면, 클라이언트 개발자는 다른 외부 애플리케이션(Naver, Google 등)의 API 을 통해 인증 과정을 위탁할 수 있습니다.
직접 하지 않고 위탁을 하는 이유를 알아보기 위해, OAuth가 없었던 시절에 알아보겠습니다.
우리 애플리케이션 "App"은 Google 로부터 email을 가져와 email 을 자동으로 정리해주는 서비스를 제공한다고 가정해보겠습니다.
그렇다면 "App" 은 사용자의 Google ID / PW 을 받아 저장하고, 이를 이용하여 사용자의 이메일을 수집합니다.
이 프로세스 과정에서 참여하는 Google, "App", 사용자는 각각의 문제점이 있습니다.
- 사용자: "App"이 Google ID/PW 을 잘 관리하는 것을 신뢰하기 어렵다.
- "App": 모든 사용자의 Google ID/PW 을 관리해야 한다. (보안 사고 방지)
- Google: 애플리케이션 "App"이 사용자의 ID/PW을 잘 관리하는 것을 신뢰하기 어렵다.
그렇기 때문에, OAuth 을 개발하여, 사용자는 "App"에 ID/PW을 직접 알려주지 않고, 다른 서비스("Google")에 접근할 수 있도록 하는 방법을 고안하였습니다.
2. Introduction
2. 1. Participants
OAuth 에서는 네 가지 참여자들이 있습니다.
- Resource Owner: 리소스 주인. 일반적으로 사용자를 의미합니다. (Gmail 소유자)
- Client: 리소스를 사용하려고 하는 서비스. 위 사례에서는 Gmail 을 이용하려는 "App"
- Resource Server: 내 정보가 실제로 저장되어있는 곳. 사례에서는 Gmail
- Authorization Server: 클라이언트("App") 이 내 리소스에 접근해도 되는지 확인하는 곳, 사례에서는 구글 인증 서버
2. 2. Process
1. 사용자가 《 클라이언트 》 앱에서 로그인 버튼 클릭
│
│ (2. 권한 서버로 권한 요청)
∨
《 클라이언트 》 --------------------------------------> 《 권한 서버 》
│
│ (3. 사용자에게 로그인 페이지 리다이렉션)
∨
《 사용자 》 <------------------------------------------ 《 권한 서버 》
│
│ (4. 사용자 로그인 및 권한 동의)
∨
《 사용자 》 --------------------------------------------> 《 권한 서버 》
│
│ (5. '인가 코드' 발급 및 리다이렉션) - 인가코드는 사용자(브라우저)에게 전달됨
∨
《 클라이언트 》 <---------------------------------------- 《 권한 서버 》
│
│ (6. '인가 코드'와 '클라이언트 비밀키'로 '접근 토큰' 요청) - 사용자에게 받은 인가코드 이용
∨
《 클라이언트 》 --------------------------------------> 《 권한 서버 》
│
│ (7. '접근 토큰' 발급)
∨
《 클라이언트 》 <---------------------------------------- 《 권한 서버 》
│
│ (8. '접근 토큰'으로 《 리소스 서버 》에 정보 요청)
∨
《 클라이언트 》 --------------------------------------> 《 리소스 서버 》
│
│ (9. 요청한 정보 반환)
∨
《 클라이언트 》 <---------------------------------------- 《 리소스 서버 》
권한 서버가 사용자에게 인가 코드(Authorization) 코드를 발급하는 이유는
사용자의 환경은 정보 노출이 되기 쉬운 브라우저 환경일 수 있고, 이 때문에 바로 접근할 수 있는 Access Token이 아닌 잠시 활용할 수 있는 인가 코드를 전달합니다.
사용자는 권한 서버로부터 인가 코드를 받고 이를 서비스 백엔드에 전달합니다. 서비스 백엔드는 받은 인가 코드와 Private Key 을 이용하여 권한 서버에 Access Token을 받습니다.
(서비스는 권한 서버에 "등록" 되어 있어야만 하며, 이 때 Client ID, Client Secret (비대칭키면 Public key), Redirect URI, Scope 등을 교환합니다.)
2. 3 Scope
사용자가 "App"이 어디까지 접근할 수 있는지를 결정하는 권한 범위입니다. Scope를 이용하여 사용자는 "App"이 Gmail이 아닌 내 Google 계정에 다른 곳에 마음대로 접근하지 못 하도록 설정할 수 있습니다.
Scope는 다음 과정을 통해 결정됩니다.
클라이언트 요청: "App"은 사용자에게 어떤 정보가 필요한지 Scope 키워드를 통해 권한 서버에 요청합니다. 구글의 "프로필 정보" 와 "이메일" 이 필요하면 profile과 email 키워드를 보냅니다.
사용자 동의: 권한 서버는 Scope 키워드를 받아 사용자에게 동의 화면을 전달합니다. (예: 프로필 정보 및 이메일 주소 접근을 허용하시겠습니까?)
인가 토큰 및 접근 토큰 발급: 사용자가 동의하면, 인가 토큰을 발급하고, 이를 이용하여 "App"이 접근 토큰을 발급할 때, 해당 Scope 가 포함된 접근 토큰을 클라이언트에 발급합니다.
권한 제한: App 이 접큰 토큰을 가지고 리소스 서버에 정보를 요청할 떄, Scope에 벗어난 정보를 요청하면 거절할 수 있습니다.
Scope는 OAuth 표준으로도 정의되어있지만, 각 서비스 제공자(리소스 서버 운영자)가 자신들의 API에 맞게 독자적으로 정의하며, 이는 개발자 문서에 공개합니다.