OAuth 2.0 에 관하여

API를 이용하여 데이터를 주고받는 신규 기능을 추가하는 업무를 맡은 적이 있다.

그 당시에는 OAuth의 개념에 대해서 제대로 알지 못한 채 스펙 다큐먼트만 보고 개발을 했었다.

(정리를 하다 보니 내가 구현한 API는 Client Credentials Grant 타입을 사용했던 것 같음..)

 

리마인드 차원에서 OAuth 2.0 대해 정리해보았다.

 

정의

OAuth란 Open Authorization, 즉 표준 인증 프로토콜으로, 인터넷 사용자가 다른 웹사이트나 애플리케이션에 비밀번호를 제공하지 않고도 자신의 정보에 접근할 수 있도록 허용하는 방법으로 일반적으로 사용된다.

소개

전통적인 클라이언트-서버 인증 모델에서는, 클라이언트는 접근 제한적인 리소스를 리소스 소유자의 인증서로 인증을 함으로써 서버에게 요청한다.
third-party 어플리케이션에게 제한적인 리소스를 제공하기 위해서, 리소스 소유자는 이러한 인증서를 third party와 함께 공유한다.
이것은 많은 문제점과 제한사항이 있다.
- Third-Party 어플리케이션은 향후 사용을 위해 리소스 소유자의 보안을 저장해야 한다.
- 서버는 비밀번호에 대한 본질적인 보안 취약성이 있음에도 비밀번호 인증을 지원해야 한다.
- Third-Party 어플리케이션은 광범위한 접근을 얻어야 한다.
- Third-Party 어플리케이션은 리소스 소유자에 의해 보호되는 리소스에 대해 지나치게 광범위한 액세스 권한을 얻습니다. 그러므로 리소스 소유자는 제한된 리소스 하위에 대한 액세스 또는 기간을 제한할 수 있는 능력이 없다.
- 리소스 소유자는 모든 Third-Party의 접근을 무효화시키기 전까지는 개별 Third-Party에 대한 접근을 무효화시킬 수 없습니다. 그리고 Third-Party의 비밀번호가 변경된다면 무효화를 시켜야 한다.
- Third-Party 어플리케이션이 손상되면 최종 사용자의 비밀번호와 해당 비밀번호로 보호되는 모든 데이터가 손상된다.

 

권한

OAuth는 4가지 권한으로 정의된다.
1. Resource Owner (리소스 소유자)
- 보호된 리소스를 접근하는 것을 가능하게 하는 개체. 리소스 소유자가 사람이면, end-user로서 언급된다.
2. Resource server (리소스 서버)
- 보호된 리소스를 제공해주는 서버, access token을 사용함으로써 보호된 리소스를 요청하고 응답받을 수 있음.
3. Client (클라이언트)
- 리소스 소유자와 그 인증서를 대신하여 보호된 리소스를 요청하는 어플리케이션.
- client라는 명칭은 서버, PC 혹은 다른 기기를 실행하는 어플리케이션인지 아닌지와 같은 특정 구현 특성을 뜻하지 않는다.
4. Authorization Server (인증 서버)
- 성공적으로 리소스 소유자에게 인증되고 인증을 얻은 후 client로 access token을 발행한 서버.

 

Protocol Flow

Abstract Protocol Flow

(A) Authorization Request (Client -> Resource Owner)
- 클라이언트는 리소스 소유자에게 인증을 요청한다.
- 인증 요청은 리소스 소유자에게 직접 혹은 바람직하게는 중개자로서 인증 서버를 통해 간접적으로 이루어질 수 있다.
(B) Authorization Grant (Resource Owner -> Client)
- 클라이언트는 리소스 소유자의 권한을 나타내는 자격 증명인 권한 부여를 받으며, 네 가지 권한 부여 유형 중 하나를 사용하거나 확장 권한 부여 유형을 사용하여 표현된다.
(C) Authorization Grant (Client -> Authorization Server)
- 클라이언트는 인증 서버와 인증함으로써 그리고 권한 부여를 나타냄으로써 access token을 요청한다.
(D) Access Token (Authorization Server -> Client)
- 인증 서버는 클라이언트를 인증하고 권한 부여를 확인하고 유효하면 access token을 발급한다.
(E) Access Token (Client -> Resource Server)
- 클라이언트는 리소스 서버로 보호된 리소스를 요청하고, access token을 나타냄으로써 인증한다.
(F) Protected Resource (Resource Server -> Client)
- 리소스 서버는 access token을 확인하고 유효하면 요청을 제공한다.

 

인증 방법

- access token을 요청하기 위해서 클라이언트는 리소스 소유자로부터 인증을 받는다.
- 인증은 클라이언트가 access token을 요청하기 위해 사용하는 인증 부여의 형태로 표현된다.
- OAuth는 authorization code, implicit, resource owner password credentials, client credentials로 총 4가지의 grant type으로 정의된다.
- 또한 추가적인 grant type을 정의하기 위한 확장 매커니즘을 제공한다.

 

1. Authorization Code Grant; 인증 코드 부여
- Authorization Code Grant는 access token과 refresh token을 얻기 위해 사용되며, 기밀(confidential) 클라이언트에 최적화되어 있다. 이는 리디렉션 기반의 flow이므로 클라이언트는 리소스 소유자의 user-agent와 상호작용을 할 수 있어야 하며(특히 웹 브라우저), 인증 서버로 부터 들어오는 요청을 (리디렉션을 통해) 수신할 수 있다.

 

[Access Token Request]

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

 

[Access Token Response]

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}

2. Implicit Grant; 암시적 부여
Implicit Grant는 access token을 얻을 때 사용하며, refresh token 발행을 지원하지 않는다. 그리고 특정 리디렉션 URI가 작동하는 것으로 알려진 public clients에게 최적화 되어 있다. 이 클라이언트는 특히 JavaScript와 같은 스크립트 언어를 사용하는 브라우저에서 구현된다. 이것은 리디렉션 기반의 flow이기 때문에 클라이언트는 리소스 소유자의 user-agent(특히 웹 브라우저)와 함께 상호작용을 할 수 있어야 하며, 인증 서버로부터 들어오는 리디렉션을 통한 요청을 수신할 수 있어야 한다. Authorization Code Grant와 다르게 클라이언트가 승인 및 access token에 대해 별도의 요청을 하는 경우 클라이언트는 access token을 인증 요청의 결과로 받는다. Implicit grant 타입은 클라이언트 인증을 포함하지 않으며, 리소스 소유자와 리디렉션 URI의 등록에 의해 달려있다. access token은 리디렉션 URI에 인코드되어있기 때문에, 리소스 소유자와 동일한 장치에 있는 다른 애플리케이션에 노출될 수 있다.

 

[Access Token Request]

GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

 

[Access Token Response]

HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600

 

3. Resource Owner Password Credentials Grant; 리소스 소유자 암호 자격 증명 부여
Resource Owner Password Credentials Grant 타입은 장치 수행 시스템 혹은 상당히 보호된 어플리케이션과 같이 리소스 소유자가 클라이언트를 신뢰할 때 적합하다. 인증 서버는 이 부여 타입이 가능할때 특별한 관리가 필요하며, 오직 다른 흐름이 실행 가능하지 않은 경우에만 허용해야 한다.
이 부여 타입은 리소스 소유자의 보안(username, password, 특히 상호적인 형식)을 얻을 수 있는 클라이언트에게 적합하다. 그리고 HTTP Basic 혹은 Digest 인증에서 OAuth으로 저장된 보안을 변경함으로써 기존 클라이언트에서 직접적인 인증 스키마로 옮길 때 사용된다.

[Access Token Request]

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=A3ddj3w

 

[Access Token Response]

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}

 

4. Client Credentials Grant; 클라이언트 자격 증명 부여
클라이언트는 자신이 제어하는 보호된 리소스 또는 이전에 인증 서버와 함께 배열된 다른 리소스 소유자의 리소스에 대한 액세스를 요청할 때 클라이언트 자격 증명(또는 기타 지원되는 인증 수단)만을 사용하여 액세스 토큰을 요청할 수 있다.
Client Credentials Grant 타입은 반드시 보안 클라이언트에게만 사용될 수 있다.

 

[Access Token Request]

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

 

[Access Token Response]

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "example_parameter":"example_value"
}

 

 

출처: 

https://en.wikipedia.org/wiki/OAuth

OAuth - Wikipedia

https://datatracker.ietf.org/doc/html/rfc6749#section-1