'Basic' HTTP 인증 스킴

이 문서는 인터넷 표준 트랙 문서입니다.

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산물입니다. 이는 IETF 커뮤니티의 합의를 반영하며, 공개 검토를 거쳐 인터넷 엔지니어링 운영 그룹(IESG)의 게시 승인을 받았습니다. 인터넷 표준에 대한 추가 정보는 RFC 5741 섹션 2에서 확인할 수 있습니다.

이 문서의 현재 상태, 정정 사항(errata), 및 피드백 제공 방법에 대한 정보는 http://www.rfc-editor.org/info/rfc7617에서 확인할 수 있습니다.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

이 문서는 사용자 ID/비밀번호 쌍을 Base64로 인코딩하여 전송하는 "Basic" 하이퍼텍스트 전송 프로토콜(HTTP) 인증 스킴을 정의합니다(HTTP 인증 스킴은 [RFC7235]에 정의되어 있습니다).

이 스킴은 사용자 ID와 비밀번호가 평문으로 네트워크를 통해 전송되기 때문에, TLS(Transport Layer Security, [RFC5246])와 같은 외부의 안전한 시스템과 함께 사용되지 않는 한 안전한 사용자 인증 방법으로 간주되지 않습니다.

"Basic" 스킴은 이전에 Section 2 of [RFC2617]에 정의되어 있었습니다. 이 문서는 정의를 갱신하고, 'charset' 인증 매개변수(Section 2.1)를 도입하여 국제화 문제도 다룹니다.

RFC 2617을 갱신하는 다른 문서로는 "Hypertext Transfer Protocol (HTTP/1.1): Authentication" ([RFC7235], 인증 프레임워크 정의), "HTTP Digest Access Authentication" ([RFC7616], "Digest" 인증 스킴 정의 갱신), 및 "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields" ([RFC7615])가 있습니다. 이 네 문서를 합하면 RFC 2617은 폐기됩니다.

Basic 인증 스킴은 클라이언트가 각 보호 공간("realm")에 대해 사용자 ID와 비밀번호로 자신을 인증해야 한다는 모델에 기반합니다. realm 값은 해당 서버에서 다른 realm과 단순 동등 비교만 가능한 자유 형식 문자열입니다. 서버는 요청된 리소스에 적용되는 보호 공간에 대해 사용자 ID와 비밀번호를 검증할 수 있는 경우에만 요청을 처리합니다.

Basic 인증 스킴은 인증 프레임워크를 다음과 같이 활용합니다.

챌린지에서는:

• 스킴 이름은 "Basic"입니다.
• 인증 매개변수 'realm'은 필수(REQUIRED)입니다 ([RFC7235], Section 2.2).
• 인증 매개변수 'charset'은 선택적(OPTIONAL)입니다 (자세한 내용은 Section 2.1 참조).
• 다른 인증 매개변수는 정의되어 있지 않습니다 — 알 수 없는 매개변수는 수신자가 무시해야(MUST) 하며, 새 매개변수는 이 명세를 개정해야만 정의될 수 있습니다.

또한 챌린지를 올바르게 파싱하는 복잡성에 대해서는 RFC7235 섹션 4.1을 참조하십시오.

스킴 및 매개변수 이름은 대소문자 구분 없이 비교됩니다.

자격증명에는 RFC7235 섹션 2.1에 정의된 "token68" 문법이 사용됩니다. 이 값은 아래에 정의된 대로 user-id와 password에 기초하여 계산됩니다.

인증 공간 내의 URI에 대한 요청 수신 시 자격증명이 없는 경우, 서버는 401 (Unauthorized) 상태 코드와 WWW-Authenticate 헤더 필드를 사용하여 챌린지를 응답할 수 있습니다([RFC7235], Section 3.1).

예를 들면:

HTTP/1.1 401 Unauthorized
Date: Mon, 04 Feb 2014 16:50:53 GMT
WWW-Authenticate: Basic realm="WallyWorld"

여기서 "WallyWorld"는 서버가 보호 공간을 식별하기 위해 할당한 문자열입니다.

프록시는 407 (Proxy Authentication Required) 상태 코드와 Proxy-Authenticate 헤더 필드를 사용하여 유사한 챌린지로 응답할 수 있습니다([RFC7235], Section 3.2).

권한을 얻기 위해 클라이언트는

1. 사용자로부터 user-id와 password를 얻고,
2. user-id, 단일 콜론(":"), password를 연결하여 user-pass를 구성하고,
3. user-pass를 옥텟 시퀀스로 인코딩하고(아래의 문자 인코딩 스킴 논의를 참조),
4. 이 옥텟 시퀀스를 Base64([RFC4648], Section 4)로 인코딩하여 US-ASCII 문자 시퀀스로 변환하여 basic-credentials를 얻습니다([RFC0020]).

이 인증 스킴의 원래 정의는 user-pass를 옥텟 시퀀스로 변환할 때 사용할 문자 인코딩 스킴을 명시하지 않았습니다. 실제로 대부분 구현체는 ISO-8859-1([ISO-8859-1]) 같은 로케일별 인코딩이나 UTF-8([RFC3629])을 선택했습니다. 이전과의 호환성 때문에 이 명세는 기본 인코딩을 US-ASCII과 호환되는 한(US-ASCII 문자를 단일 옥텟으로 매핑하는 경우) 미정의로 남깁니다.

user-id와 password에는 어떤 제어 문자도 포함되어서는 안 됩니다(MUST NOT) (자세한 내용은 RFC5234 Appendix B.1의 "CTL" 참조).

또한 user-id에 콜론 문자가 포함된 경우는 무효입니다. user-pass 문자열에서 첫 번째 콜론이 user-id와 password를 구분하기 때문입니다; 첫 번째 콜론 이후의 텍스트는 비밀번호의 일부로 취급됩니다. 따라서 콜론을 포함한 user-id는 user-pass 문자열에 인코딩할 수 없습니다.

많은 사용자 에이전트가 사용자가 입력한 user-id에 콜론이 포함되어 있는지 확인하지 않고 user-pass 문자열을 생성한다는 점을 유의하십시오; 수신자는 이 경우 사용자 이름 입력의 일부를 비밀번호의 일부로 처리할 것입니다.

사용자 에이전트가 user-id "Aladdin"과 비밀번호 "open sesame"을 보내려면 다음 헤더 필드를 사용합니다:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

US-ASCII 문자 집합을 벗어나는 문자를 포함한 user-id나 password는 통신 당사자 양측이 사용할 문자 인코딩 스킴에 합의하지 않으면 상호 운용성 문제가 발생합니다. 서버는 'charset' 매개변수(Section 2.1)를 사용하여 "UTF-8"을 선호한다고 표시함으로써 클라이언트가 해당 인코딩으로 전환할 가능성을 높일 수 있습니다.

'realm' 매개변수는 텍스트로 간주될 수 있는 데이터를 담지만, [RFC7235]는 비-US-ASCII 문자를 신뢰성 있게 전송하는 방법을 정의하지 않습니다. 이 문제는 해당 명세를 개정할 때 해결되어야 할 알려진 이슈입니다.

Basic 인증 스킴은 안전한 사용자 인증 방법이 아니며, 전송되는 자격증명은 물리적 네트워크 상에서 평문으로 전송됩니다. HTTP는 Basic 인증에 일회용 비밀번호 등과 같은 향상 기능을 추가하는 것을 막지 않습니다.

Basic 인증의 가장 심각한 결함은 사용자 비밀번호가 물리적 네트워크를 통해 평문으로 전송된다는 점입니다. 많은 다른 인증 스킴은 이 문제를 해결합니다.

Basic 인증은 비밀번호를 평문으로 전송하므로, 민감하거나 가치 있는 정보를 보호하기 위해(예: HTTPS 없이) 사용해서는 안 됩니다(SHOULD NOT).

Basic 인증의 일반적인 사용 사례는 식별 목적입니다 — 예를 들어 서버의 정확한 사용 통계를 수집하기 위해 사용자가 user-id와 password를 제공하도록 요구하는 경우입니다. 이 경우 사용자가 스스로 비밀번호를 선택하게 허용하지 않고 서버가 사용자에게 user-id와 password를 발급한다면 위험이 적다고 생각할 수 있습니다. 그러나 사용자가 여러 비밀번호를 관리하기 어렵기 때문에 자주 동일한 비밀번호를 재사용하는 경향이 있어 위험이 발생합니다.

서버가 사용자가 자체 비밀번호를 선택하도록 허용하면 위협은 서버의 문서 무단 접근뿐 아니라 사용자가 동일한 비밀번호를 사용하여 보호하는 다른 시스템의 자원에 대한 무단 접근까지 포함합니다. 또한 서버의 비밀번호 데이터베이스에 저장된 많은 비밀번호가 다른 사이트의 비밀번호일 수 있습니다. 따라서 시스템 소유자나 관리자가 해당 정보를 안전하게 유지하지 않으면 모든 사용자가 타 사이트에 대한 무단 접근 위험에 노출될 수 있습니다. 이는 보안 및 개인정보 문제를 야기합니다(RFC6973 참조). 동일한 user-id/비밀번호 조합이 이메일이나 건강 포털 같은 다른 계정에 사용되는 경우 개인 정보가 노출될 수 있습니다.

Basic 인증은 위조 서버에 의한 스푸핑에도 취약합니다. 사용자가 자신이 인증된 정보를 가진 호스트에 연결하고 있다고 믿게끔 유도될 수 있고, 실제로는 악의적 서버에 연결되면 공격자는 비밀번호를 요청하여 저장한 뒤 오류를 가장할 수 있습니다. 서버 구현자는 이러한 위조를 방지해야 합니다; 특히 기존 연결의 메시지 프레이밍 제어를 가져올 수 있는 소프트웨어 구성요소는 주의해서 사용하거나 아예 사용하지 않아야 합니다(예: RFC3875의 NPH 스크립트 등).

Basic 인증을 구현하는 서버 및 프록시는 요청을 인증하기 위해 어떤 형태로든 사용자 비밀번호를 저장해야 합니다. 이러한 비밀번호는 비밀번호 데이터가 유출되더라도 쉽게 복원될 수 없도록 저장되어야 합니다. 사용자가 스스로 비밀번호를 설정할 수 있도록 허용되는 경우에는 특히 중요합니다. 사용자는 약한 비밀번호를 선택하고 인증 영역(realm) 전반에 걸쳐 재사용하는 경향이 알려져 있기 때문입니다. 우수한 비밀번호 해싱 기법에 대한 전체 논의는 이 문서의 범위를 벗어나지만, 서버 운영자는 비밀번호 데이터 유출 시 사용자에 대한 위험을 최소화하기 위해 노력해야 합니다. 예를 들어 서버는 사용자 비밀번호를 평문으로 저장하거나 솔트가 없는 다이제스트로 저장하는 것을 피해야 합니다. 최신 비밀번호 해싱 기법에 대한 자세한 논의는 "Password Hashing Competition" (<https://password-hashing.net>)을 참조하십시오.

UTF-8 문자 인코딩과 정규화 사용은 추가적인 보안 고려사항을 수반합니다; 자세한 내용은 RFC3629 섹션 10 및 RFC5198 섹션 6을 참조하십시오.

IANA는 "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"를 유지 관리합니다([RFC7235]) <http://www.iana.org/assignments/http-authschemes>.

"Basic" 인증 스킴의 항목은 이 명세를 참조하도록 업데이트되었습니다.

스킴 정의는 [RFC7235]와 같은 최신 명세와 일치하도록 다시 작성되었습니다.

새로운 인증 매개변수 'charset'이 추가되었습니다. 이것은 순수히 권고적이므로 기존 구현은 변경할 필요가 없으며, 추가 정보를 이용하고자 하는 경우에만 변경하면 됩니다.

이 명세는 이전에 RFC 2617에서 정의된 "Basic" HTTP 인증 스킴의 정의를 인계받았습니다. 우리는 해당 명세 작업에 기여한 John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, 및 Lawrence C. Stewart에게 감사드립니다. 추가 감사의 글은 RFC2617 섹션 6을 참조하십시오.

user-pass에 사용되는 문자 인코딩 스킴과 관련된 국제화 문제는 2000년에 모질라 버그로 보고되었습니다 (참조: <https://bugzilla.mozilla.org/show_bug.cgi?id=41489> 및 더 최근의 <https://bugzilla.mozilla.org/show_bug.cgi?id=656213>). 이 문제를 새로운 auth-param으로 해결하자는 아이디어는 Andrew Clover의 것이었습니다.

이 개정에 대한 피드백을 준 HTTPAUTH 작업 그룹 구성원들과 리뷰어들(예: Stephen Farrell, Roy Fielding, Daniel Kahn Gillmor, Tony Hansen, Bjoern Hoehrmann, Kari Hurtta, Amos Jeffries, Benjamin Kaduk, Michael Koeller, Eric Lawrence, Barry Leiba, James Manger, Alexey Melnikov, Kathleen Moriarty, Juergen Schoenwaelder, Yaron Sheffer, Meral Shirazipour, Michael Sweet, 및 Martin Thomson)에게 감사드립니다.