기본 인증
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
기본 인증은 웹 리소스에 대한 접근 제어를 구현하는 간단한 기술로, HTTP 쿠키, 세션 식별자 또는 로그인 페이지가 필요하지 않다. HTTP 헤더의 표준 필드를 사용하지만, 자격 증명이 Base64로 인코딩되어 전송되므로 보안에 취약하여 HTTPS와 함께 사용되는 것이 일반적이다. 서버는 401 Unauthorized 상태와 WWW-Authenticate 헤더 필드를 사용하여 인증을 요청하며, 클라이언트는 Authorization 헤더 필드에 Base64로 인코딩된 사용자 이름과 비밀번호를 담아 서버에 전송한다.
더 읽어볼만한 페이지
- 컴퓨터 접근 제어 프로토콜 - RADIUS
RADIUS는 네트워크 접근 관리에 사용되는 AAA 프로토콜로, 클라이언트-서버 모델을 기반으로 사용자 인증 및 권한 부여를 수행하며 다양한 환경에서 활용된다. - 컴퓨터 접근 제어 프로토콜 - OAuth
OAuth는 웹/앱 환경에서 사용자 인증 및 API 접근 권한 위임을 위한 개방형 표준 프로토콜로, 버전 1.0과 2.0을 거쳐 2.1 초안이 진행 중이며, 널리 사용되지만 복잡성과 보안 문제에 대한 논쟁도 있다. - HTTP - HTTPS
HTTPS는 HTTP에 보안 기능이 더해진 통신 규약으로, 웹 브라우저와 서버 간 통신을 암호화하여 보안을 강화하지만, 인증서 비용, 서버 부하, 혼합 콘텐츠 문제 등의 단점도 존재한다. - HTTP - HTTP 쿠키
HTTP 쿠키는 웹 서버가 사용자 브라우저에 저장하는 작은 텍스트 파일로, 웹 사이트가 방문 기록, 로그인 정보 등을 기억하여 HTTP의 상태 비저장성을 보완하고 세션 관리, 개인 설정, 사용자 추적 등에 활용되지만 개인 정보 보호 및 보안 문제에 대한 논란이 있다.
| 기본 인증 | |
|---|---|
| HTTP 접근 인증 방식 | |
| 종류 | HTTP 인증 |
| 인증 방식 | 사용자 이름과 비밀번호 |
| 보안 수준 | 낮음 (Base64 인코딩만 사용) |
| 사용 프로토콜 | HTTP |
| RFC | RFC 7617 (기본 인증) |
| 상세 정보 | |
| 설명 | HTTP에서 사용자 인증을 위해 사용되는 간단한 인증 방식임. 클라이언트가 서버에 요청을 보낼 때, 사용자 이름과 비밀번호를 Base64로 인코딩하여 HTTP 헤더에 포함시켜 전송함. |
| 보안 취약점 | Base64 인코딩은 암호화가 아니므로, 네트워크 트래픽을 가로채면 쉽게 사용자 이름과 비밀번호를 알아낼 수 있음. HTTPS와 함께 사용하거나, 더 안전한 인증 방식(Digest 인증 등)을 사용하는 것이 권장됨. |
| 사용 예시 | 웹 서버에서 특정 리소스에 접근 제한을 걸 때, 사용자 이름과 비밀번호를 요구하는 팝업 창을 띄우는 방식으로 구현될 수 있음. |
| 장점 | 구현이 간단하고, 대부분의 웹 브라우저에서 지원함. |
| 단점 | 보안에 취약하며, 사용자 이름과 비밀번호가 평문으로 전송될 수 있음. |
2. 특징
HTTP 기본 인증(BA) 구현은 쿠키, 세션 식별자 또는 로그인 페이지가 필요하지 않기 때문에 웹 리소스에 대한 접근 제어를 적용하는 가장 간단한 기술이다. HTTP 기본 인증은 HTTP 헤더의 표준 필드를 사용한다.
HTTP 기본 인증(BA)은 전송되는 자격 증명의 기밀성을 보장하지 않는다. 자격 증명은 단순히 Base64로 인코딩될 뿐, 암호화나 암호화 해시를 거치지 않기 때문이다. 따라서 기본 인증은 HTTPS와 함께 사용하여 기밀성을 확보하는 것이 일반적이다.
3. 보안
서버 측 메커니즘이 없으면 자격 증명에 대한 무차별 대입 공격을 방지하거나 탐지하기 어렵다.[3]
3. 1. 보안 취약점 및 대응
HTTP 기본 인증(BA)은 쿠키, 세션 식별자, 로그인 페이지 없이 웹 리소스에 대한 접근 제어를 적용하는 간단한 기술로, HTTP 헤더의 표준 필드를 사용한다.
기본 인증(BA) 메커니즘은 전송되는 자격 증명에 대한 기밀성을 보장하지 않는다. 자격 증명은 단순히 Base64로 인코딩될 뿐, 암호화되거나 암호화 해시되지 않기 때문이다. 따라서 기본 인증은 일반적으로 기밀성을 위해 HTTPS와 함께 사용된다.
BA 필드는 각 HTTP 요청 헤더에 포함되어야 하므로, 웹 브라우저는 사용자에게 계속해서 사용자 이름과 비밀번호를 묻지 않도록 일정 기간 동안 자격 증명을 캐시한다. 캐싱 정책은 브라우저마다 다르다.
HTTP는 웹 서버가 클라이언트에게 사용자를 "로그아웃"하도록 지시하는 방법을 제공하지 않는다. 그러나 특정 웹 브라우저에서 캐시된 자격 증명을 지우는 방법이 있다. 한 가지 방법은 의도적으로 잘못된 자격 증명을 사용하여 동일한 도메인의 URL로 사용자를 리디렉션하는 것이다. 하지만 이 동작은 브라우저 및 버전에 따라 일관성이 없다.[3] 마이크로소프트 인터넷 익스플로러는 캐시된 자격 증명을 지우는 JavaScript 메서드를 제공한다.[4]
최신 브라우저에서는 기본 인증에 대한 캐시된 자격 증명이 브라우징 기록을 지울 때 함께 지워지는 경우가 많다. 대부분의 브라우저는 사용자가 자격 증명만 지울 수 있도록 허용하지만, 옵션을 찾기 어렵고, 방문한 모든 사이트에 대한 자격 증명을 지우는 경우가 많다.[5][6]
서버 측 메커니즘이 없으면 자격 증명에 대한 무차별 대입 공격을 방지하거나 탐지하기 어렵다.
3. 2. 브라우저 캐싱 문제
기본 인증(BA) 필드는 각 HTTP 요청의 헤더에 전송되어야 하므로, 웹 브라우저는 사용자에게 지속적으로 사용자 이름과 비밀번호를 묻는 것을 피하기 위해 자격 증명을 일정 기간 동안 캐시해야 한다. 캐싱 정책은 브라우저마다 다르다.
HTTP는 웹 서버가 클라이언트에게 사용자를 "로그아웃"하도록 지시하는 방법을 제공하지 않는다. 그러나 특정 웹 브라우저에서 캐시된 자격 증명을 지우는 여러 가지 방법이 있다. 그중 하나는 의도적으로 잘못된 자격 증명을 사용하여 동일한 도메인의 URL로 사용자를 리디렉션하는 것이다. 그러나 이 동작은 다양한 브라우저 및 브라우저 버전 간에 일관성이 없다.[3] 마이크로소프트 인터넷 익스플로러는 캐시된 자격 증명을 지우는 전용 JavaScript 메서드를 제공한다.[4]
최신 브라우저에서는 기본 인증에 대한 캐시된 자격 증명이 일반적으로 브라우징 기록을 지울 때 지워진다. 대부분의 브라우저는 사용자가 특히 자격 증명만 지울 수 있도록 허용하지만, 옵션을 찾기 어려울 수 있으며 일반적으로 방문한 모든 사이트에 대한 자격 증명을 지운다.[5][6]
4. 프로토콜
HTTP 기본 인증(BA)은 쿠키, 세션 식별자, 로그인 페이지 없이 웹 리소스에 대한 접근 제어를 적용하는 간단한 기술이다. HTTP 기본 인증은 HTTP 헤더의 표준 필드를 사용한다.[9]
HTTP 클라이언트와 HTTP 서버 간의 통신은 다음과 같은 절차로 이루어진다.
# 클라이언트는 인증이 필요한 페이지를 요청한다. (일반적으로 사용자 이름과 비밀번호는 보내지 않음)
# 서버는 401 응답 코드를 반환하고, 인증 영역(authentication realm) 및 방식(기본 인증) 정보를 클라이언트에 알린다.
# 클라이언트는 인증 영역(접속하는 컴퓨터나 시스템에 대한 설명)을 사용자에게 제시하고, 사용자 이름과 비밀번호 입력을 요구한다. (사용자는 여기서 취소 가능)
# 사용자가 사용자 이름과 비밀번호를 입력하면, 클라이언트는 요청에 인증 헤더를 추가하여 다시 전송한다.
# 인증에 성공하면 서버는 요청을 처리한다. 실패하면 서버는 다시 401 응답 코드를 반환하고, 클라이언트는 사용자에게 다시 사용자 이름과 비밀번호 입력을 요구한다.
다음은 인증 성공 예시이다. (번호는 위 통신 절차와 일치)
'''1. 인증을 수반하지 않는 요청''':
```http
GET /private/index.html HTTP/1.1
Host: example.com
```
'''2. 인증이 필요함을 나타내는 서버의 응답''':
```http
HTTP/1.1 401 Authorization Required
Date: Wed, 11 May 2005 07:50:26 GMT
Server: Apache/1.3.33 (Unix)
WWW-Authenticate: Basic realm="SECRET AREA"
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
(여기에 사람이 읽을 수 있는 에러 메시지가 들어간다)
```
'''3. (클라이언트에 의한 제시, 및 사용자에 의한 입력)''':
통신은 이루어지지 않음
'''4. 인증을 수반하는 요청''' (사용자 이름 "root", 비밀번호 "password"):
```http
GET /private/index.html HTTP/1.1
Host: example.com
Authorization: Basic cm9vdDpwYXNzd29yZA
```
'''5. 서버의 응답'''
```http
HTTP/1.1 200 OK
Date: Wed, 11 May 2005 07:50:26 GMT
(이하 생략)
4. 1. 서버 측
서버가 인증되지 않은 요청을 받은 후 사용자 에이전트가 서버에 인증을 요청할 때, 서버는 'HTTP 401 Unauthorized' 상태 라인[7]과 'WWW-Authenticate' 헤더 필드를 포함하는 응답을 보내야 한다.[8]기본 인증을 위한 'WWW-Authenticate' 헤더 필드는 다음과 같이 구성된다.
```
WWW-Authenticate: Basic realm="사용자에게 표시되는 영역"
```
서버는 'charset' 매개변수를 포함하도록 선택할 수 있다.[3]
```
WWW-Authenticate: Basic realm="사용자에게 표시되는 영역", charset="UTF-8"
```
이 매개변수는 서버가 클라이언트가 사용자 이름과 비밀번호를 인코딩하는 데 UTF-8을 사용할 것으로 예상한다는 것을 나타낸다.
전형적인 기본 인증에서의 HTTP 클라이언트와 HTTP 서버 간의 통신은 다음과 같다.
# 클라이언트는 인증이 필요한 페이지를 요청한다. 그러나 일반적으로 여기서 사용자 이름과 비밀번호를 보내지 않는다. 왜냐하면 클라이언트는 해당 페이지가 인증을 필요로 하는지 여부를 알지 못하기 때문이다.
# 서버는 401 응답 코드를 반환하고, 인증 영역(authentication realm)이나 인증 방식 (기본 인증)에 관한 정보를 클라이언트에 알린다.
# 이를 받은 클라이언트는 인증 영역(통상, 액세스하고 있는 컴퓨터나 시스템의 간단한 설명)을 사용자에게 제시하고, 사용자 이름과 비밀번호의 입력을 요구한다. 사용자는 여기서 취소할 수도 있다.
# 사용자에 의해 사용자 이름과 비밀번호가 입력되면, 클라이언트는 요청에 인증 헤더를 추가하여 다시 전송한다.
# 인증에 성공하면, 서버는 인증이 필요한 페이지의 요청을 처리한다. 한편, 사용자 이름이나 비밀번호가 틀렸을 때는, 서버는 다시 401 응답 코드를 반환한다. 이에 따라 클라이언트는 다시 사용자에게 사용자 이름과 비밀번호의 입력을 요구한다.
4. 2. 클라이언트 측
HTTP 기본 인증(BA)은 웹 리소스에 대한 접근 제어를 적용하는 가장 간단한 기술로, 쿠키, 세션 식별자, 로그인 페이지가 필요 없다. 대신 HTTP 헤더의 표준 필드를 사용한다.[9]사용자 에이전트(브라우저)가 서버에 인증 자격 증명을 보낼 때는 `Authorization` 헤더 필드를 사용한다.[9]
`Authorization` 헤더 필드는 다음과 같이 구성된다.[9]
- 사용자 이름과 비밀번호는 콜론(`:`)으로 결합된다. (사용자 이름에는 콜론을 사용할 수 없다.)
- 결합된 문자열은 옥텟 시퀀스로 인코딩된다. 기본 문자 집합은 US-ASCII와 호환되지만, 서버는 `charset` 매개변수로 UTF-8 사용을 제안할 수 있다.[9]
- 결과 문자열은 Base64(+/ 및 패딩 사용) 변형을 사용하여 인코딩된다.
- 인증 방법과 공백 문자(예: "Basic ")가 인코딩된 문자열 앞에 추가된다.
예를 들어, 사용자 이름이 'Aladdin'이고 비밀번호가 'open sesame'인 경우, `Authorization` 헤더 필드는 다음과 같다.
`Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==`
일반적인 기본 인증에서 HTTP 클라이언트와 서버 간의 통신 순서는 다음과 같다.
1. 클라이언트는 인증이 필요한 페이지를 요청한다. (일반적으로 사용자 이름과 비밀번호는 보내지 않는데, 페이지가 인증을 필요로 하는지 모르기 때문이다.)
2. 서버는 401 응답 코드를 반환하고, 인증 영역(authentication realm) 및 방식(기본 인증)에 대한 정보를 클라이언트에 알린다.
3. 클라이언트는 인증 영역(접속하는 컴퓨터나 시스템에 대한 설명)을 사용자에게 제시하고, 사용자 이름과 비밀번호 입력을 요구한다. (사용자는 여기서 취소할 수 있다.)
4. 사용자가 사용자 이름과 비밀번호를 입력하면, 클라이언트는 요청에 인증 헤더를 추가하여 다시 전송한다.
5. 인증에 성공하면 서버는 요청을 처리한다. 실패하면 서버는 다시 401 응답 코드를 반환하고, 클라이언트는 사용자에게 다시 사용자 이름과 비밀번호 입력을 요구한다.
5. 통신 과정
전형적인 기본 인증에서의 HTTP 클라이언트와 HTTP 서버 간의 통신 과정은 다음과 같다.
1. 클라이언트는 인증이 필요한 페이지를 요청한다. 그러나 일반적으로 여기서 사용자 이름과 비밀번호를 보내지 않는다. 왜냐하면 클라이언트는 해당 페이지가 인증을 필요로 하는지 여부를 알지 못하기 때문이다.
2. 서버는 401 응답 코드를 반환하고, 인증 영역(authentication realm)이나 인증 방식(기본 인증)에 관한 정보를 클라이언트에 알린다.
3. 이를 받은 클라이언트는 인증 영역(통상, 액세스하고 있는 컴퓨터나 시스템의 간단한 설명)을 사용자에게 제시하고, 사용자 이름과 비밀번호의 입력을 요구한다. 사용자는 여기서 취소할 수도 있다.
4. 사용자에 의해 사용자 이름과 비밀번호가 입력되면, 클라이언트는 요청에 인증 헤더를 추가하여 다시 전송한다.
5. 인증에 성공하면, 서버는 인증이 필요한 페이지의 요청을 처리한다. 한편, 사용자 이름이나 비밀번호가 틀렸을 때는, 서버는 다시 401 응답 코드를 반환한다. 이에 따라 클라이언트는 다시 사용자에게 사용자 이름과 비밀번호의 입력을 요구한다.
다음은 인증에 성공한 경우의 예시이다. (번호는 위의 "통신 흐름"과 일치한다.)
'''1. 인증을 수반하지 않는 요청''':
```http
GET /private/index.html HTTP/1.1
Host: example.com
```
'''2. 인증이 필요함을 나타내는 서버의 응답''':
```http
HTTP/1.1 401 Authorization Required
Date: Wed, 11 May 2005 07:50:26 GMT
Server: Apache/1.3.33 (Unix)
WWW-Authenticate: Basic realm="SECRET AREA"
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
(여기에 사람이 읽을 수 있는 에러 메시지가 들어간다)
```
'''3. (클라이언트에 의한 제시, 및 사용자에 의한 입력)''':
＜통신은 이루어지지 않음＞
'''4. 인증을 수반하는 요청''' (사용자 이름 "root", 비밀번호 "password"):
```http
GET /private/index.html HTTP/1.1
Host: example.com
Authorization: Basic cm9vdDpwYXNzd29yZA
```
'''5. 서버의 응답'''
```http
HTTP/1.1 200 OK
Date: Wed, 11 May 2005 07:50:26 GMT
(이하 생략)
참조
[1]
간행물
Announcing Access Authorization Documentation
http://1997.webhisto[...]
2022-09-10
[2]
웹사이트
Hypertext Transfer Protocol -- HTTP/1.0
https://www.w3.org/P[...]
W3C
2022-02-07
[3]
웹사이트
Is there a browser equivalent to IE's ClearAuthenticationCache?
https://stackoverflo[...]
StackOverflow
2013-03-15
[4]
웹사이트
"IDM_CLEARAUTHENTICATIONCACHE command identifier"
https://docs.microso[...]
Microsoft
2013-03-15
[5]
웹사이트
540516 - Usability: Allow users to clear HTTP Basic authentication details ('Logout')
https://bugzilla.moz[...]
2020-08-06
[6]
웹사이트
Clear browsing data - Computer - Google Chrome Help
https://support.goog[...]
2020-08-06
[7]
IETF
Access Authentication
Internet Engineering Task Force
1996-05
[8]
IETF
Hypertext Transfer Protocol -- HTTP/1.0
Internet Engineering Task Force
[9]
IETF
The 'Basic' HTTP Authentication Scheme
Internet Engineering Task Force
[10]
간행물
Announcing Access Authorization Documentation
http://1997.webhisto[...]
2022-09-10
[11]
웹인용
Hypertext Transfer Protocol -- HTTP/1.0
https://www.w3.org/P[...]
W3C
2022-02-07
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com