RFC 7235 (HTTP/1.1)

Hypertext Transfer Protocol (HTTP/1.1) : Authentication

하이퍼텍스트 전송 프로토콜(HTTP)은 분산, 협업, 하이퍼미디어 정보 시스템을 위한 상태 비 저장 애플리케이션-레벨 프로토콜이다. 이 문서는 HTTP 인증 프레임워크를 정의한다.

1. Introduction

HTTP는 확장 가능한 일련의 challenge-response 인증 scheme을 통해 접근 제어 및 인증에 대한 일반적인 프레임워크를 제공하며, 이 프레임워크는 클라이언트 요청을 요구하기 위해 서 버가 사용할 수 있고 클라이언트가 인증 정보를 제공할 수 있다. 본 문서는 “Hypertext Transfer Protocol (HTTP/1.1) : Message Synthetic and Routing” [RFC7230] 에서 아키텍처 측면에서 HTTP/1.1 인증을 정의하고, 이전에 정의된 "HTTP Authentication: Basic and Digest Access Authentication" [RFC2617]에서 일반적인 프레임워크와, 이전에 정의 된 "Hypertext Transfer Protocol — HTTP/1.1" [RFC2616]에서 관련된 필드 및 상태 코드를 포함한다.

IANA Authentication Scheme Registry(Section 5.1)에는 RFC 2617에서 이전에 정의한 "basic" 및 "digest" 인증 scheme을 포함하여 등록된 인증 scheme과 해당 명세가 열거되어 있다.

1.1. Conformance and Error Handling

1.2. Syntax Notation

2. Access Authentication Framework

2.1. Challenge and Response

HTTP는 서버에 의해 클라이언트 요청을 challenge(이하 질의)하고 클라이언트가 인증 정보를 제공하는 데 사용할 수 있는 간단한 challenge-response(질의-응답) 인증 프레임워크를 제공한다. 대소문자를 구분하지 않는 토큰으로 인증 방식을 식별하는 수단으로 사용하며, 그 scheme을 통한 인증 획득에 필요한 추가 정보가 뒤따른다. 후자는 쉼표로 구분된 매개변수 목록 또는 base64로 인코딩된 정보를 저장할 수 있는 단일 문자 시퀀스가 될 수 있다.

• 인증 매개변수는 name=value 쌍이며, 여기서 이름 토큰은 대소문자를 구분하지 않고 일치하

  며, 각 매개변수 이름은 질의 당 한 번만 발생해야 한다.(MUST)

401 (Unauthorized) 응답 메시지는 요청된 리소스에 적용할 수 있는 적어도 하나 이상의 질의가 포함된 WWW-Authenticate 헤더 필드를 포함하여 사용자 에이전트의 권한을 질의하기 위해 원서버에서 사용된다.

407 (Proxy Authentication Required) 응답 메시지는 요청된 리소스에 대해 프록시에 사용되는 적어도 하나 이상의 질의를 가지는 Proxy-Authenticate 헤더 필드를 포함하여 클라이언트의 인증을 질의하기 위해 프락시가 사용한다.

액세스 권한이 충분하지 않은 유효한 자격 증명을 받은 서버는 403(Forbidden) 상태 코드([RFC7231]의 Section 6.5.3)로 응답해야 한다.

HTTP는 접근 인증을 위해 애플리케이션을 이 간단한 challenge-response 프레임워크로 제한하지 않는다. 전송 레벨 또는 메시지 캡슐화를 통한 인증, 인증 정보를 지정하는 추가 헤더 필드와 같은 추가 메커니즘을 사용할 수 있다. 그러나 이러한 추가 메커니즘은 이 명세에 의해 정의되지 않는다.

2.2. Protection Space (Realm)

"realm" 인증 매개변수는 보호 범위를 표시하고자 하는 인증 scheme에서 사용하도록 예약되어 있다.

보호 공간은 접속 중인 서버의 표준 루트 URI(유효한 요청 URI의 scheme 및 권한 구성 요소, [RFC7230]의 Section 5.5 참조)에 의해 영역 값과 함께 정의된다. 이러한 영역은 서버의 보호된 리소스를 보호 공간의 집합으로 분할할 수 있도록 허용하며, 각 영역은 자체 인증 scheme 및/또는 인증 데이터베이스를 가지고 있다. 영역 값은 일반적으로 원서버에 의해 할당되는 문자열로, 인증 sheme에 특정한 추가적인 의미론을 가질 수 있다. 응답은 동일한 auth-scheme을 사용하지만, 다른 영역으로 인해 여러 가지 문제를 일으킬 수 있다는 점에 유의한다.

역사적 이유로, 발신자는 quoted-string 구문만 생성해야 한다. 수신자는 오랫동안 두 가지 표기법을 모두 수용해 온 기존 클라이언트와의 상호 운용성을 극대화하기 위해 토큰과 quoted-string 구문을 모두 지원해야 할 수 있다.

3. Status Code Definitions

3.1. 401 Unauthorized

401 (Unauthorized) 상태 코드는 대상 리소스에 대한 유효한 인증 자격 증명이 없기 때문에 요청이 적용되지 않았음을 나타낸다. 401 응답을 생성하는 서버는 대상 리소스에 적용되는 적어도 하나 이상의 challenge를 포함하는 WWW-Authenticate 헤더 필드(Section 4.1)를 전송해야 한다.(MUST)

요청에 인증 자격 증명이 포함된 경우, 401 응답은 해당 자격 증명에 대한 인증이 거부되었음을 나타낸다.

3.2. 407 Proxy Authentication Required

407 (Proxy Authentication Required) 상태 코드는 401 (Unauthorized)과 유사하지만, 프록시를 이용하기 위해서는 클라이언트가 스스로 인증해야 한다는 것을 나타낸다.

• 프록시는 대상 리소스에 대해 해당 프록시에 적용되는 과제가 포함된 Proxy-Authenticate 헤더 필드

  (Section 4.3)를 전송해야 한다.(MUST)

4. Header Field Definitions

이 절에서는 HTTP 인증 프레임워크와 관련된 헤더 필드의 구문 및 의미론을 정의한다.

4.1. WWW-Authenticate

"WWW-Authenticate" 헤더 필드는 대상 리소스에 적용할 수 있는 인증 scheme(s) 및 매개 변수를 나타낸다.

WWW-Authenticate = 1#challenge

• 401 (Unauthorized) 응답을 생성하는 서버는 적어도 하나의 challenge가 포함된 WWW- Authenticate 헤더 필드를 전송해야 한다.(MUST)

• 응답을 전달하는 프록시는 해당 응답의 WWW-Authenticate 필드를 수정해서는 안된

  다.(MUST NOT)

사용자 에이전트는 필드 값을 구문 분석할 때 특히 주의할 것을 권고한다. 필드 값은 둘 이상의 질의를 포함할 수 있으며 각 질의에는 쉼표로 구분된 인증 매개 변수 목록이 포함될 수 있다. 게다가, 헤더 필드 자체는 여러 번 발생할 수 있다.

WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basic realm="simple"

이 헤더 필드에는 영역 값이 "apps"인 "Newauth" scheme과 영역 값이 "simple"인 추가 매개 변수 "type" 및 "title"인 "Basic" scheme인 다른 두 가지 질의가 포함되어 있다.

4.2. Authorization

Authorization = credentials

요청이 인증되고 영역이 지정된 경우, 동일한 자격 증명이 이 영역 내의 다른 모든 요청에 대 해 유효한 것으로 간주된다.(인증 scheme 자체에 질의 값에 따라 달라지는 자격 증명이나 동기화된 시계 사용과 같이 달리 요구하지 않는다고 가정).

• 요청을 전달하는 프록시는 해당 요청의 Authorization 필드를 수정해서는 안 된다.(MUST NOT)

HTTP 캐시에 의한 Authorization 필드의 취급에 관한 세부사항 및 요건은 [RFC7234]의 Section 3.2를 참조한다

4.3. Proxy-Authenticate

"Proxy-Authenticate" 헤더 필드는 이 유효한 요청 URI에 대해 프락시에 적용되는 인증 scheme(s)와 파라미터를 나타내는 적어도 하나 이상의 challenge로 구성된다([RFC7230]의 Section 5.5). 프록시는 자신이 생성하는 각 407(Proxy Authentication Required) 응답에서 Proxy-Authenticate 헤더 필드를 하나 이상 전송해야 한다.(MUST)

Proxy-Authenticate = 1#challenge

WWW-Authenticate와 달리 Proxy-Authenticate 헤더 필드는 응답 체인의 다음 아웃바운드 클라이언트에만 적용된다. 주어진 프록시를 선택한 클라이언트만 인증에 필요한 자격 증명 을 가질 가능성이 높기 때문이다. 그러나, 대기업 네트워크 내의 사무실 및 지역 캐싱 프락시 와 같은 동일한 관리 도메인 내에서 여러 개의 프록시를 사용하는 경우, 사용자 에이전트에 의 해 자격 증명이 생성되어 소비될 때까지 계층을 통과하는 것이 일반적이다. 따라서 이러한 구성에서는 각 프록시가 동일한 질의 집합을 전송하기 때문에 Proxy-Authenticate가 전달되는 것처럼 나타날 것이다.

4.4. Proxy-Authorization

"Proxy-Authorization" 헤더 필드는 클라이언트가 인증을 필요로 하는 프록시에 대해 자신 (또는 그 사용자)을 식별할 수 있도록 한다. 이 값은 요청되는 리소스의 프록시 및/또는 영역에 대한 클라이언트의 인증 정보를 포함하는 자격 증명으로 구성된다

Proxy-Authorization = credentials

Proxy-Authorization 헤더 필드는 Authorization 필드를 사용한 인증을 요구한 다음 인바운드 프록시에만 적용된다. 체인에 여러 프록시가 사용되는 경우, Proxy-Authenticate 헤더 필 드는 자격 증명을 받기를 기대했던 첫 번째 인바운드 프록시에 의해 소비된다. 프록시는 프록시들이 주어진 요청을 협력하여 인증하는 메커니즘인 경우 클라이언트 요청의 자격 증명을 다음 프록시에게 전달할 수 있다.

5. IANA Considerations

5.1. Authentication Scheme Registry

"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"는 challenge와 자격 증명의 인증 scheme에 대한 네임스페이스를 정의한다. 그것은 만들어졌고 현재<http://www.iana.org/assignments/http-authschemes>에서 유지되고 있다.

5.1.1. Procedure

등록에는 다음 필드가 포함되어야 한다.

• Authentication Scheme Name

• Pointer to specification text

• Notes (optional)

5.1.2. Considerations for New Authentication Schemes

HTTP Authentication Framework에는 새로운 인증 scheme이 작동하는 방식에 제약을 가하는 측면이 있다.

• HTTP 인증은 상태 저장 없는 것으로 가정된다. 요청 인증에 필요한 모든 정보는 이전 요청을 기억하는 서버에 의존하지 않고 요청에 제공되어야 한다.(MUST)

• 기본 커넥션에 기반하거나 이에 구속되는 인증은 이 명세의 범위를 벗어나며, 인증된 사용자가 아닌 다른 당사자가 커넥션을 사용할 수 없도록 조치를 취하지 않는 한 본질적으로 결함이 있다([RFC7230] Section

  2.3 참조).

• 인증 매개변수 "realm"은 Section 2.2에 설명된 보호 공간을 정의하기 위해 예약되어 있다. 새로운 scheme은 그 정의와 호환할 수 없는 방법으로 그것을 사용해서는 안 된다.(MUST NOT)

Authorization 헤더 필드(e.g., 새로 정의된 헤더 필드 사용)에서 자격 증명을 소지하지 않기로 선택한 새로운 인증 scheme에서는 Cache-Control 요청 지시어(예: "no-store", [RFC7234]의 Section 5.2.1.5) 또는 응답 지시어(예: "private")의 사용을 의무화하여 캐싱을 명시적으로 허용하지 않아야 한다.

5.2. Status Code Registration

<http://www.iana.org/assignments/http-status-codes>에 위치한 "Hypertext Transfer Protocol (HTTP) Status Code Registry"는 아래의 등록과 함께 업데이트되었다.

5.3. Header Field Registration

HTTP 헤더 필드는 <http://www.iana.org/assignments/message-headers/>에서 유지되는 "Message Headers" 레지스트리 내에 등록된다.

6. Security Considerations

6.1. Confidentiality of Credentials

HTTP 인증 프레임워크는 인증 정보의 기밀성을 유지하기 위한 단일 메커니즘을 정의하지 않는다. 대신, 각 인증 scheme은 전송 전에 인증 정보가 인코딩되는 방법을 정의한다. 이는 향후 인증 scheme 개발에 유연성을 제공하지만, 자체로 기밀성을 제공하지 않거나, 재실행 공 격으로부터 충분히 보호하지 못하는 기존 제도의 보호에는 부적당하다. 또한 서버가 각 개별 사용자별로 특정한 자격 증명을 기대하는 경우, 자격 증명 내의 내용이 기밀로 유지되더라도 해당 사용자를 식별하는 효과가 있을 것이다.

HTTP는 헤더 필드의 기밀 전송을 제공하기 위해 기본 전송 또는 세션 레벨 커넥션의 보안 속성에 의존한다. 즉, 서버가 이 프레임워크를 사용하여 인증된 사용자에 대한 접근을 제한하는 경우, 서버는 사용된 인증 scheme의 특성에 따라 연결이 적절하게 보안되도록 할 필요가 있다. 예를 들어, 개별 사용자 인증에 의존하는 서비스에서는 자격 증명을 교환하기 전에 TLS("Transport Layer Security", [RFC5246])로 보안된 커넥션을 필요하는 경우가 많다.

6.2. Authentication Credentials and Idle Clients

기존 HTTP 클라이언트와 사용자 에이전트는 일반적으로 인증 정보를 무기한 보존한다. 프로토콜은 사용자 에이전트에 의해 자격 증명을 얻거나 관리하는 방법을 인식하지 못하기 때문에, HTTP는 원서버가 클라이언트가 이러한 캐시된 자격 증명을 삭제하도록 지시하는 메커니즘을 제공하지 않는다. 자격 증명을 만료하거나 취소하는 메커니즘은 인증 scheme 정의의 일부로 지정할 수 있다.

자격 증명 캐싱이 애플리케이션의 보안 모델을 방해할 수 있는 상황에는 다음이 포함되지만 이에 국한되지는 않는다.

• 장기간 유휴 상태였던 클라이언트, 그 이후에 서버가 사용자에게 자격 증명을 재계약하도록 할 수 있다.

• 세션 종료 표시(예: 페이지의 "로그아웃" 또는 "커밋" 버튼)가 포함된 애플리케이션은 클라이언트가 자격 증명을 보유할 더 이상의 이유가 없음을 "알고 있다".

자격 증명을 캐시하는 사용자 에이전트는 사용자 제어하에 캐시된 자격 증명을 삭제하기 위한 쉽게 액세스할 수 있는 메커니즘을 제공하도록 권장된다.

6.3. Protection Spaces

보호 공간을 설정하는 "realm" 메커니즘에만 의존하는 인증 scheme은 원서버의 모든 리소스에 자격 증명을 노출시킬 것이다. 리소스로 인증된 요청을 성공적으로 수행한 클라이언트는 동일한 원서버의 다른 리소스에 대해 동일한 인증 자격 증명을 사용할 수 있다. 이렇게 하면 다른 리소스가 다른 리소스에 대한 인증 자격 증명을 수집할 수 있다.

이는 원서버가 동일한 표준 루트 URI(Section 2.2)에 따라 여러 당사자를 위한 리소스를 호스트하는 경우에 특히 중요하다. 가능한 완화 전략으로는 인증 자격 증명에 대한 직접 액세스 제한(i.e., Authorization 요청 헤더 필드의 내용을 사용할 수 없도록 함)과 각 당사자에 대해 다른 호스트 이름(또는 포트 번호)을 사용하여 보호 공간을 분리하는 것이 포함된다.

7. Acknowledgments

Appendix A. Changes from RFCs 2616 and 2617

HTTP 인증에 대한 프레임워크는 이제 RFC 2617이 아닌 이 문서에 의해 정의된다.

"realm" 매개변수는 더 이상 질의에 항상 필요하지 않다. 따라서 ABNF는 인증 매개변수 없이 질의 허용한다. (Section 2)

auth-param 리스트에 대한 "token68" 대안이 "Basic"과 같은 기존 인증 scheme과의 일관성을 위해 추가되었다. (Section 2)

Appendix B. Imported ABNF

Appendix C. Collected ABNF