서버가 사용자가 누구인지 식별할 수 있어야 한다. 서버가 사용자가 누구인지 알면, 그 사용자가 어떤 작업이나 리소스에 접근할 수 있는지 결정할 수 있다. 인증은 당신이 누구인지 증명하는 것이다. 보통 사용자 이름과 비밀번호를 입력해서 인증하는데 HTTP는 자체적인 인증 관련 기능을 제공한다.
1. 인증
인증은 당사자가 누구인지 증명하는 것이다. 여권이나 운전 면허증 같은 신분증을 보여주는 것은 누구인지 증명해 보이는 것이다. 자동 전화기에 PIN 번호를 입력하거나 컴퓨터의 대화상자에 비밀번호를 입력하는 것 역시 누구인지 증명하는 것이다.
1.1 인증 프로토콜과 헤더
HTTP는 필요에 따라 고쳐 쓸 수 있는 제어 헤더를 통해 다른 인증 프로토콜에 맞춰 확장할 수 있는 프레임워크를 제공한다. 인증 프로토콜은 HTTP 인증 헤더에 기술되어 있다.
참고* 현대 HTTP의 인증요구/응답 프로토콜을 사용하는 인증 프로토콜로는 OAuth가 있다. OAuth는 모바일 기기 같은 다양한 애플리케이션에서 API인증을 위해 사용하는 프로토콜이다.
| 단계 | 헤더 | 설명 | 메서드/상태 |
|---|---|---|---|
| 요청 | 첫 번째 요청에는 인증 정보가 없다. | ||
| 인증요구 | WWW-Authenticate | 서버는 사용자에게 사용자 이름과 비밀번호를 제공하라는 지시의 의미로 401 상태코드와 함께 요청을 반려한다. 서버에는 각각 다른 비밀번호가 있는 영역들이 있을것이므로, 서버는 WWW-Authenticate 헤더에 해당 영역을 설명해 놓는다. | 401 Unauthorized |
| 인증 | Authorization | 사용자 이름과 비밀번호를 기술한 Authorization 헤더를 함께 보낸다. | GET |
| 성공 | Authentication-Info | 인증 정보가 정확하면 서버는 문서와 함께 응답한다. | 200 OK |
1.2 보안 영역
보안 영역은 저마다 다른 사용자 권한을 요구한다. 서버가 클라이언트로 인증요구를 할 때, realm 지시자가 기술되어 있는 WWW-Authenticate헤더로 구분한다.
2. 기본 인증
기본 인증은 가장 잘 알려진 HTTP 인증 규약이다. 거의 모든 주요 클라이언트와 서버에 기본 인증이 구현되어 있다.
기본 인증에서 웹 서버는 클라이언트의 요청을 거부하고 유효한 사용자 이름과 비밀번호를 요구할 수 있다. 서버는 200 대신 401 상태 코드와 함께 클라이언트가 접근하려고 했던 보안 영역을 WWW-Authenticate에 기술해서 응답하여 인증요구를 시작한다. 인증 정보를 포함하여 요청하라는 응답을 받은 브라우저는 사용자에게 계정과 비밀번호를 입력할 수 있는 대화상자를 연다. 여기서 계정과 비밀번호는 사용자가 해당 영역에 접근 권한이 있는지 검사하는데 사용된다. 브라우저는 사용자가 입력한 사용자 이름과 비밀번호를 Authorization 요청 헤더 안에 암호화해서 서버로 다시 보낸다.
HTTP 기본 인증은 사용자 이름과 비밀번호를 콜론으로 이어서 합치고 base-64 인코딩 메서드를 사용해 인코딩 한다.
2.1 프록시 인증
중개 프록시 서버를 통해 인증할 수도 있다. 어떤 회사는 사용자들이 회사의 서버나 LAN이나 무선 네트워크에 접근하기 전에 프록시 서버를 거치게 하여 사용자를 인증한다. 프록시 서버에서 접근 정책을 중앙 관리 할 수 있기 때문에 회사 리소스 전체에 대한 통합적인 접근 제어를 하기 위해서 프록시 서버를 사용하면 좋다.
프록시 인증은 웹 서버의 인증과 헤더와 상태 코드만 다르고 절차는 같다.
| 웹 서버 | 프록시 서버 |
|---|---|
| 비인증 상태코드 : 401 | 비인증 상태 코드 : 407 |
| WWW-Authenticate | Proxy-WWW-Authenticate |
| Authorization | Proxy-Authorization |
| Authentication-Info | Proxy-Authentication-Info |
3. 기본 인증의 보안 결함
- base-64로 인코딩된 사용자 이름과 비밀번호는 인코딩 절차를 반대로 수행해서 어렵지 않게 디코딩할 수 있다. base-64로 인코딩된 비밀번호는 사실상 ‘비밀번호 그대로’ 보내는 것과 다름없다. 어떤 좋지 않은 의도를 가진 외부 업자가 기본 인증으로 보낸 사용자 이름과 비밀번호를 가로채는 상황을 볼 수도 있다. 모든 HTTP 트랜잭션을 SSL 암호화 채널을 통해 보내거나, 보안이 더 강화된 다이제스트 인증 같은 프로토콜을 사용하는 것이 좋다.
- 보안 비밀번호가 디코딩하기에 더 복잡한 방식으로 인코딩되어 있다고 하더라도 여전히 제3자는 읽기 힘든 사용자 이름과 비밀번호를 캡처한 다음, 그것을 그대로 원 서버에 보내서 인증에 성공하고 서버에 접근할 수 있다. 기본 인증은 이러한 재전송 공격을 예방하기 위한 어떤 일도 하지 않는다.
- 메시지의 인증 헤더를 건드리지는 않지만, 그 외 다른 부분을 수정해서 트랜잭션의 본래 의도를 바꿔버리는 프록시나 중개자가 중간에 개입하는 경우, 기본 인증은 정상적인 동작을 보장하지 않는다.
- 기본 인증은 가짜 서버의 위장에 취약하다. 만약 사용자가 가짜 서버나 가짜 게이트에 연결되어 있는데도 사용자는 기본 인증을 수해하는 검증된 서버에 연결되어 있다고 믿고 있다면 공격자는 사용자에게 비밀번호를 요청하고 그것을 나중에 사용할 목적으로 저장한 다음 에러가 난 척을 할 수 있다.
종합하면 기본 인증은 일반적인 환경에서 개인화나 접근을 제어하는데 편리하지만 사용자 이름과 비밀번호를 악의적인 개인들에게 숨기기 위해 암호화된 데이터 전송(SSL 같은)과 함께 연계해서 사용하는 게 바람직하다.
