OAuth 2.0 개요

들어가기 앞서

OAuth 2.0은 인가(Authorization)를 위한 표준 프로토콜입니다.

웹 애플리케이션, 데스크톱 애플리케이션, 휴대폰 및 디바이스에 대한 특정한 인가(Authorization)흐름을 제공하여

클라이언트 개발을 단순하게 해줍니다.

OAuth 2.0 Authorization 프레임워크를 통해

제3자가 리소스 소유자(HTTP 서비스 사용자)와 서비스 사이에서 상호작용을 하거나,

(제3자가) 스스로 권한을 획득하는 방법 등을 통해 액세스 권한을 획득하고,

HTTP 서비스에 대하여 액세스할 수 있습니다.

0. 개요

전통적인 클라이언트-서버 인증(Authentication) 모델에서

클라이언트는 서버에서 보호중인(인가된 사용자만 접근가능한) 자원에 액세스를 요청하기 위해

리소스 소유자의 자격 증명(credentials)을 사용하여 서버와 인증합니다.

제3자 애플리케이션에게 제한된 자원에 대한 액세스 권한을 부여하기 위해

리소스 소유자는 자신의 자격 증명을 제3자와 공유합니다.

이로 인해 여러 문제와 제한 사항이 발생합니다.

제한 사항

1. 제3자 애플리케이션은 리소스 소유자(서비스 사용자)의 자격 증명(credentials)을 나중에 사용할 수 있도록 저장해야 합니다.
   암호는 (일반적으로) 평문으로 저장합니다.
2. 서버는 (암호에 보안 취약점이 내재되어 있어도) 암호 인증을 지원해야 합니다.
3. 제3자 애플리케이션은 (리소스 소유자의 보호된 리소스에 대한) 너무 광범위한 액세스를 얻게 되어,
   리소스 소유자가 특정 리소스에 대해 액세스를 제한하는 등 권한을 세밀하게 관리하기 어렵게 됩니다.
   (예컨대, 리소스 소유자가 앨범을 공유할 때, 제3자가 모든 사진의 접근 권한을 갖게 되면 리소스 소유자는 일부 사진을 공유하고 싶지 않아도 공유될 수 있습니다)
4. 리소스 소유자는 액세스 권한을 가진 제3자 중, 특정 제 3자에 대한 액세스만을 철회할 수 없습니다.
   철회하려면 모든 제3자에 대한 액세스를 철회하고, 암호를 변경해야 합니다.
5. 제3자의 애플리케이션이 손상되면 리소스 소유자(최종 사용자)의 암호와 해당 암호로 보호된 모든 데이터의 손상으로 이어집니다.

OAuth는 전술한 문제(전통적인 모델의 제한 사항)를 해결하기 위해 인가(authorization) 계층을 도입하고

클라이언트의 역할을 리소스 소유자의 역할과 분리함으로써 문제를 해결합니다.

OAuth에서 클라이언트는 (리소스 서버에서 호스팅된) 리소스 소유자가 제어하는 리소스에 액세스를 요청합니다.

이때, 클라이언트는 리소스 소유자의 자격 증명(credentials)과는 다른 자격 증명(credentials)을 발급받습니다.

 

클라이언트는 보호된 리소스에 액세스하기 위해

리소스 소유자의 자격 증명(credentials)을 사용하는 대신

액세스 토큰(AT, Access Token)을 발급받습니다.

 

액세스 토큰은 특정 범위(scope), 수명(유효기간) 및 기타 속성을 나타내는 문자열입니다.

(리소스 소유자의 승인을 받은)제3자 클라이언트는 인가(authorization) 서버로부터 액세스 토큰을 발급받습니다.

클라이언트는 액세스 토큰을 사용하여 (리소스 서버에서 호스팅되는) 보호된 리소스에 액세스합니다.

예컨대,
리소스 소유자(최종 사용자)는 인쇄 서비스(클라이언트)에 자신의 이름 및 비밀번호를 노출하지 않고,
인쇄 서비스(클라이언트)가 사진 공유 서비스(리소스 서버)에 있는 사용자의 사진에 대한 액세스 권한을 부여할 수 있습니다.
대신, 사용자는 사진 공유 서비스(리소스 서버)가 신뢰하는 인가(authorization)서버에 직접 인증하고,
인쇄 서비스(클라이언트)에 대한 (접근 권한이 있는)액세스 토큰을 발급받습니다.

---

1. 역할 Roles

OAuth는 네 가지 역할을 정의합니다.

리소스 소유자, 리소스 서버, 클라이언트, 인가 서버

1. 리소스 소유자
   보호된 리소스에 대한 액세스를 허용할 수 있는 엔티티입니다.
   리소스 소유자가 사람인 경우 최종 사용자라고 부르기도 합니다.
2. 리소스 서버
   액세스 토큰을 사용하여 보호된 리소스 요청을 수락하고, 응답할 수 있는, 보호된 리소스를 호스팅하는 서버입니다.
3. 클라이언트
   리소스 소유자의 승인하에 보호된 리소스에 액세스를 요청하는 응용 프로그램입니다.
   특정 구현 특성(데스크톱, 서버, 또는 다른 디바이스)을 의미하지 않습니다
4. 인가 서버
   리소스 소유자에 대한 인증을 진행하고, 클라이언트에게 인가된 액세스 토큰을 발급하는 서버입니다.
   인가 서버와 리소스 서버를 동일하게 구성할 수도 있습니다.
   하나의 인가 서버는 여러 리소스 서버에게 액세스 토큰을 발급할 수 있습니다.

2. 프로토콜 흐름

추상화한 프로토콜 흐름 (대략적인 흐름 파악을 위한 자료로, 권장되는 방식은 아닙니다)

1. 인가요청 - 클라이언트 → 리소스 소유자

클라이언트는 리소스 소유자로부터 인가를 요청합니다.

인가 요청은 리소스 소유자에게 직접적으로 하거나 인가서버를 통해 간접적으로 이루어질 수 있습니다.

(인가서버를 통한 방법을 권장합니다)

2. 인가(권한 부여) - 리소스 소유자 → 클라이언트

클라이언트는 리소스 소유자로부터 액세스 권한을 인가받습니다.

(권한 유형은 서버에서 설정한 것에 따라 달라질 수 있습니다)

3. 인가(권한 부여) - 클라이언트 → 인가 서버

클라이언트는 인가 서버에 인증을 요청하고, 리소스 소유자에 대한 액세스 권한을 인가합니다.

그리고 인가 서버에게 (액세스 권한을 가진) 액세스 토큰의 발급을 요청합니다.

4. 액세스 토큰 발급 - 인가 서버 → 클라이언트

인가 서버는 클라이언트를 인증하고 인가 정보를 검증합니다.

유효한 경우, 클라이언트에게 액세스토큰을 발급합니다.

(만약 리프레시 토큰을 발급한다면, 이 단계에서 액세스 토큰과 함께 발급합니다)

5. 액세스 토큰으로 요청 - 클라이언트 → 리소스 서버

클라이언트는 리소스 서버에게 보호된(접근 권한이 필요한) 리소스를 요청하고,

(액세스 권한을 인가받은)액세스 토큰을 제시하여 인증합니다.

6. 보호된 리소스 제공 - 리소스 서버 → 클라이언트

리소스 서버는 액세스 토큰의 유효성을 검사합니다.

유효한 경우, 요청에 대한 응답(리소스 제공)을 합니다.

3. 인가(권한 부여)

인가(권한 부여)는 클라이언트가 액세스 토큰을 발급받기 위해 사용하는 자격 증명(credential)으로,

리소스 소유자의 (보호된 자원에 액세스 하기 위한)인가를 나타냅니다.

클라이언트가 (리소스 서버에 있는, 리소스 소유자의)보호된 리소스에 액세스할 권한을 얻을 수 있게 합니다.

4. 액세스 토큰 Access Token

액세스 토큰은

1. 보호된 리소스에 액세스하는 데 사용되는 자격 증명(credential)입니다.
2. 클라이언트에 발급된 권한을 나타내는 문자열입니다.
   (이 문자열은 일반적으로 클라이언트가 알 수 없는 내용으로 표현됩니다)
3. (리소스 소유자가 부여한)권한의 범위 및 유효기간을 담고 있으며,
   리소스 서버와 인가 서버가 그 권한을 따릅니다.
4. 인가 정보를 검색하는 데 사용되는 식별자로 쓰이거나,
   인가 정보를 검증하는 방식 그 자체일 수도 있습니다.
   다시 말하자면, 토큰은 데이터와 서명으로 이루어진 문자열일 수도 있습니다.
   (서명으로 검증할 수 있습니다)
5. 다양한 승인구조(예컨대, 사용자 이름과 비밀번호)를 대체할 수 있습니다.
   리소스 서버가 다루기 쉬운, 추상화된 구조로 제공합니다.
   이러한 추상화는 (액세스 토큰을 발급받을 때 사용되는 권한보다 더) 제한된 권한을 가진 액세스 토큰을 발급할 수 있게 합니다.
   또한, 리소스 서버의 부하를 감소시킬 수 있습니다.
6. 리소스 서버의 보안 요구 사항에 따라 다양한 형식, 구조 및 활용 방법(예: 암호화 유형)을 가질 수 있습니다.

5. 리프레시 토큰 Refresh Token

리프레시 토큰은

1. 액세스 토큰을 발급하는 데 사용되는 자격증명(credentials)입니다.
2. 인가 서버가 클라이언트에게 발행합니다.
   액세스 토큰이 만료되거나 유효하지 않을 때, 새로운 액세스 토큰을 발급할 때 사용합니다.
   동일하거나 더 좁은 범위의 권한을 갖는 추가 액세스 토큰을 발급하기 위해 사용할 수 있습니다.
   (액세스 토큰은 리소스 소유자에 의해 허용된 것보다 짧은 유효기간, 더 적은 권한을 가질 수 있습니다)
3. 리프레시 토큰을 발급하는 것은 인가서버의 재량에 따른 선택 사항입니다.
   만약 인가 서버가 리프레시 토큰을 발급한다면, 액세스 토큰을 발급할 때 함께 발급하여 제공합니다.
4. 리소스 소유자가 클라이언트에게 부여한 권한을 나타내는 문자열입니다.
   이 문자열은 (일반적으로) 클라이언트가 알 수 없는 내용으로 표현됩니다.
5. 인가 정보를 검색하기 위해(혹은 다시 가져오기 위해) 사용되는 식별자 역할을 합니다.
   (식별자는 리프레시 토큰을 사용하여 1.인가서버로부터 새로운 액세스 토큰을 발급받거나 2.필요한 인가 정보를 검색합니다)

액세스 토큰과 달리 리프레시 토큰은 인가 서버에서만 사용할 수 있으며 리소스 서버로 전송되지 않습니다.

 

만료된 액세스 토큰을 리프레시 토큰으로 재발급하는 과정

1. 인가(권한 부여) - 클라이언트 → 인가 서버

클라이언트는 인가 서버에게 인증을 요청하고, 인가 정보를 제공하여 액세스 토큰을 요청합니다.

2. 액세스 토큰 & 리프레시 토큰 발급 - 인가 서버 → 클라이언트

인가 서버는 클라이언트를 인증하고, 인가 정보의 유효성을 검사합니다.

유효하다면, 인가 서버에서 액세스 토큰과 리프레시 토큰을 클라이언트에게 발급합니다.

3. 액세스 토큰을 제시하여 리소스 요청 - 클라이언트 → 리소스 서버

클라이언트는 액세스 토큰을 리소스 서버에 제시함으로써 리소스 서버에 보호된 리소스를 요청합니다.

4. 토큰 유효성 검사 후 보호된 리소스 응답 - 리소스 서버 → 클라이언트

리소스 서버는 클라이언트가 제시한 액세스 토큰의 유효성을 검사합니다.

유효하다면, 요청을 처리합니다.

5. 만료된 액세스 토큰 제시 - 클라이언트 → 리소스 서버

액세스 토큰이 만료될 때까지 리소스를 요청 - 응답하는 과정을 진행할 수 있습니다.

클라이언트가 액세스 토큰의 만료를 알고 있다면, 7번을 수행합니다

(인가 서버에게 리프레시 토큰을 제시하여 액세스 토큰 재발급을 요청하는 단계).

클라이언트가 액세스 토큰의 만료를 알고 있지 않다면, 만료된 토큰으로 리소스를 요청합니다.

6. 액세스 토큰 유효성 오류 - 리소스 서버 → 클라이언트

클라이언트가 인가 서버에 제시한 액세스 토큰이 유효하지 않기 때문에

인가 서버가 클라이언트에게 “토큰 유효성 오류”를 반환합니다.

7. 리프레시 토큰을 제시하여 액세스 토큰 발급 요청 - 클라이언트 → 인가 서버

클라이언트는 인가 서버에 인증을 요청하고 리프레시 토큰을 제시하여 새로운 액세스 토큰을 요청합니다.

(클라이언트 인증에 대한 요구 사항은 클라이언트 유형 및 인가 서버 정책에 따라 달라질 수 있습니다)

8. 액세스 토큰(혹은 새로운 리프레시 토큰) 발급 - 인가 서버 → 클라이언트

인가 서버는 클라이언트를 인증하고, 리프레시 토큰의 유효성을 검사합니다.

유효하다면, 인가 서버에서 새로운 액세스 토큰을(, 필요하다면 리프레시 토큰도) 클라이언트에게 발급합니다.

6. 상호 운용성

OAuth 2.0은 보안 속성이 잘 정의되어 있는, 윤택한 인가(authorization) 프레임워크를 제공합니다.

다양한 선택 사항을 결정할 수 있으며, 확장성이 높습니다.

 

참조

https://oauth.net/2/

OAuth 2.0 — OAuth

https://datatracker.ietf.org/doc/html/rfc6749

RFC 6749: The OAuth 2.0 Authorization Framework