OAuth 2.0 RFC6749 문서 1장을 번역합니다.

0.Abstract

OAuth 2.0 인가 프레임워크는 리소스 소유자와 HTTP 서비스 사이의 승인 상호작용을 통해 사용자를 대신하여 혹은, 자기 자신을 대신하여 접근을 얻도록 하여 서드 파티 애플리케이션이 제한된 접근을 얻을 수 있도록 합니다.

1. Introduction

전통적인 클라이언트-서버 인증 모델에서, 클라이언트는 리소스 소유자의 자격 증명을 사용하여 인증함으로써 서버 상의 접근 제한된 리소스, 즉 보호된 리소스를 요청한다. 서드 파티 애플리케이션에게 제한된 리소스를 제공하기 위해, 리소스 소유자는 자신의 자격 증명을 서드 파티와 공유한다. 여기에는 몇 가지 문제와 한계가 있다.

• 서드 파티 애플리케이션은 미래에 사용하기 위해 리소스 소유자의 자격 증명(주로 평문으로 이루어진 패스워드)을 저장해야 한다.
  서버는 패스워드에 보안 취약점이 내재되어 있어도 패스워드 인증을 지원해야 한다.

• 서드 파티 애플리케이션은 접근 가능한 리소스의 부분이나 접근 기한에 대한 제한 없이 리소스 소유자의 리소스에 대해 과도하게 넓은 접근을 얻는다.

• 리소스 소유자는 모든 서드 파티에 대한 접근을 취소하지 않고서는 개개의 서드 파티 애플리케이션에 대한 접근을 취소할 수 없으며, 이는 서드 파티의 비밀번호를 바꿔야만 한다.

• 임의의 서드 파티 애플리케이션의 정보 유출은 최종 사용자의 패스워드와 이 패스워드에 의해 보호되는 모든 데이터에 대한 유출로 이어진다.

OAuth는 인가 계층 도입과 리소스 소유자와 클라이언트의 역할을 구분함으로써 이러한 문제들을 다룬다. OAuth에서 클라이언트는 리소스 소유자에 의해 통제되고 리소스 서버에 의해 호스트되는 리소스에 대한 접근을 요청하며, 리소스 소유자에 따라 다른 자격 증명의 집합이 발급된다.

보호된 리소스에 접근하기 위해 리소스 소유자의 자격 증명을 사용하는 대신, 클라이언트는 구체적인 범위, 제한시간, 다른 접근 속성을 나타내는 문자열인 접근 토큰을 얻는다. 접근 토큰은 인가 서버가 의해 리소스 소유자의 승인으로 서드 파티 클라이언트에게 발급한다. 클라이언트는 리소스 서버가 호스트하는 보호된 리소스에 접근하기 위해 이 접근 토큰을 사용한다.

1.1 Roles

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

• resource owner
  : 보호된 리소스에 대한 접근을 승인할 수 있는 개체. 리소스 소유자가 사람인 경우, 이는 최종 사용자로 참조된다.

• resource server
  : 제한된 리소스를 호스팅하는 서버, 접근 토큰을 사용하는 제한된 리소스 요청을 받고 응답할 수 있다.

• client
  : 인가를 이용하여 리소스 소유자를 대신해 제한된 리소스 요청을 만드는 애플리케이션.

• authorization server
  : 리소스 소유자를 성공적으로 인증하고 인가를 얻은 뒤 클라이언트에게 접근 토큰을 발급하는 서버.

1.2 Protocol Flow

OAuth 2.0의 추상적인 흐름은 네 가지 역할 간의 상호작용을 기술하며 다음 단계를 포함한다:

• (A) 클라이언트는 리소스 소유자로부터의 인가를 요청한다. 인가 요청은 리소스 소유자에게 직접 요청할 수도 있지만, 중간의 인증 서버를 통해 간접적으로 하는 것이 바람직하다.

• (B) 클라이언트는 리소스 소유자의 인가를 나타내는 자격 증명인 승인 인가를 받는다. 승인 인가는 이 명세에서 정의된 네 개의 승인 유형 중 하나 또는 확장된 승인 유형으로 발행된다. 인가 승인 형식은 클라이언트가 인가를 요청하는 방법과 인가 서버가 지원하는 유형에 의존한다.

• (C) 클라이언트는 인가 서버에 인증하고 인가 승인을 제시함으로써 접근 토큰을 요청한다.

• (D) 인가 서버는 클라이언트를 인증하고 인가 승인이 유효한지 확인하고, 유효한 경우 접근 토큰을 발급한다.

• (E) 클라이언트는 리소스 서버에 보호된 리소스를 요청하고 접근 토큰을 제시함으로써 인증한다.

• (F) 리소스 서버는 접근 토큰이 유효한지 확인하고, 유효한 경우 요청을 받아들인다.

클라이언트가 리소스 소유자로부터 인가 승인을 얻는 방법으로는 [그림 3]의 중개 인가 서버를 사용하는 것이 바람직하다.

1.3 Authorization Grant

인가 승인은 클라이언트가 접근 토큰을 얻기 위해 사용되는 것으로 리소스 소유자 (보호된 리소스에 대한 접근)의 인가를 나타내는 자격 증명이다. 이 명세는 네 가지 승인 유형 (인가 코드, 암시적 승인, 리소스 소유자 패스워드 자격 증명, 클라이언트 자격 증명) 을 정의한다.

1.3.1 Authorization Code

인가 코드는 클라이언트와 리소스 소유자 사이에 중개자로서 인가 서버를 사용하여 획득된다. 리소스 소유자에게 인가를 직접 요청하는 대신, 클라이언트는 (에이전트를 통해) 인가 서버로 안내하고 인가 서버는 리소스 소유자를 인증하고 클라이언트는 인가 코드를 획득한다. 리소스 소유자는 오직 인가 서버로만 인증하기 때문에, 리소스 소유자의 자격 증명은 절대 클라이언트와 공유되지 않는다. (보안상의 이점)

1.3.2 Implicit

암시적 승인은 Javascript와 같은 스크립트 언어를 사용하는 브라우저에서 구현된 클라이언트에 최적화된 단순화된 인가 코드 흐름이다. 암시적 승인 흐름에서는 (리소스 소유자 인가의 결과로) 클라이언트에게 인가 코드를 발급하는 대신, 클라이언트에게 접근 토큰이 직접 발급된다. (인가 코드와 같은) 중개 자격 증명이 발급되지 않기 때문에, 이 인가 유형을 암시적 승인으로 부른다.

암시적 승인 흐름에서 접근 토큰을 발급할 때, 인가 서버는 클라이언트를 인증하지 않는다. 특정한 경우에, 클라이언트의 신원은 클라이언트에게 접근 토큰을 전달하기 위해 사용되는 리다이렉션 URI를 통해 확인될 수 있다. 접근 토큰은 리소스 소유자 혹은 리소스 소유자의 사용자 에이전트 접근을 통해 다른 애플리케이션에 노출될 수도 있다.

암시적 승인은, 접근 토큰을 얻기 위한 왕복을 줄이기 때문에 일부 클라이언트의 반응성과 효율을 향상시킨다. 하지만 이러한 편의성은 보안상의 이슈가 발생한다.

1.3.3 Resource Owner Password Credentials

리소스 소유자 패스워드 자격 증명(유저 네임과 패스워드)은 접근 토큰을 얻는 인가 승인에 직접 사용될 수 있다. 자격 증명은 리소스 소유자와 클라이언트 사이에 높은 신뢰가 있으며, (인가 코드와 같은) 다른 인가 승인 유형을 사용할 수 없는 경우에만 사용되어야 한다.

이 유형이 리소스 소유자의 자격 증명에 직접 접근해야 함에도 불구하고, 리소스 소유자 자격 증명이 하나의 요청과 접근 토큰으로 교환하는 데 사용된다. 이 승인 유형은 자격 증명을 긴 수명으로 가진 접근 토큰이나 갱신 토큰으로 교환함으로써, 클라이언트가 리소스 소유자의 자격 증명을 저장할 필요가 없도록 할 수 있다.

1.3.4 Client Credentials

클라이언트 자격 증명은 보통 클라이언트가 자기 자신을 대신하여 (클라이언트가 리소스 소유자이기도 하여) 행동하고 있는 경우 혹은 인가 서버와 조정된 보호된 리소스에 대한 미리 접근된 요청인 경우 사용될 수 있다.

1.4 Access Token

접근 토큰 은 보호된 리소스에 접근하는 데 사용되는 자격 증명이다. 접근 토큰은 클라이언트에게 발급된 인가를 나타내는 문자열이다. 문자열은 보통 클라이언트가 알아볼 수 없다. 토큰은 접근의 구체적인 범위(scope)와 기간(lift-time)을 명시하며, 리소스 소유자에 의해 생성되고, 리소스 서버와 인가 서버에 의해 사용된다.

토큰은 인가 정보를 조회하는 데 사용되는 식별자를 의미할 수도 있고, 특정 데이터와 서명으로 구성된 토큰 문자열로 자기 자신이 포함하고 있을 수도 있다. 클라이언트가 토큰을 사용하기 위해 이 명세의 범위를 벗어나는 추가적인 인증 자격 증명이 필요할 수도 있다.

접근 토큰은 리소스 서버가 이해할 수 있는 하나의 토큰으로 다른 인가 구성(e.g., 유저네임과 패스워드)를 대체하는 추상 계층을 제공 한다. 이 추상화는 접근 토큰을 얻는 데 사용되는 인가 승인보다 더 제한적으로 접근 토큰을 발급할 수 있게 할 뿐만 아니라, 인증 서버가 넓은 범위의 인증 방식을 이해할 필요가 없게 한다.

접근 토큰은 리소스 서버의 보안 요구사항에 기반하여 암호화 특성을 가질 수 있다.

1.5 Refresh Token

갱신 토큰은 접근 토큰을 얻는 데 사용되는 자격 증명이다. 갱신 토큰은 인증 서버에 의해 클라이언트에게 발급되며 현재 접근 토큰이 유효하지 않거나 만료된 경우 새 접근 토큰을 얻거나, 동일하거나 더 좁은 범위로 추가적인 접근 토큰을 얻기 위해 사용된다.

갱신 토큰은 클라이언트가 리소스 소유자에 의해 인가가 승인되었음을 나타내는 문자열이다. 문자열은 보통 클라이언트가 알아볼 수 없다. 토큰은 인가 정보를 조회하는 데 사용되는 식별자를 의미한다. 접근 토큰과는 달리, 갱신 토큰은 오직 인가 서버에서만 사용되며, 리소스 서버로는 절대 보내지지 않는다.

그림 2의 흐름은 다음의 단계를 포함한다:

• (A) 클라이언트는 인가 서버로 인증하고 인가 승인을 제시함으로써 접근 토큰을 요청한다.

• (B) 인가 서버는 클라이언트를 인증하고 인가 승인을 확인한다. 유효한 경우, 접근 토큰과 갱신 토큰을 발급한다.

• (C) 클라이언트는 접근 토큰을 제시함으로써 보호된 리소스에 대한 요청을 생성한다.

• (D) 리소스 서버는 접근 토큰을 확인하고 유효한 경우, 요청을 받아들인다.

• (E) 접근 토큰이 만료될 때까지 단계 (C)와 (D)를 반복한다.

• (F) 접근 토큰이 유효하지 않기 때문에, 리소스 서버는 유효하지 않은 토큰 오류를 반환한다.

• (G) 클라이언트는 인가 서버에 인증하고 갱신 토큰을 제시하여 새 접근 토큰을 요청한다. 클라이언트 인증 요구사항은 클라이언트 유형과 인가 서버의 정책에 기반한다.

• (H) 인가 서버는 클라이언트를 인증하고 갱신 토큰이 유효한지 확인한다. 만약 유효하면, 새 접근 토큰(과 선택적으로, 새 갱신 토큰)을 발급한다.