[3. 식별, 인가, 보안] 12장) 기본 인증

웹 사이트에 있는 개인의 프로필이나 개인이 작성한 문서는 소유자 동의 없인 권한이 없는 사용자는 볼 수 없어야 하기 위해선 서버가 사용자가 누구인지 식별할 수 있어야 한다.

보통 누구인지 사용자 이름과 비밀번호를 입력해 인증한다. HTTP는 자체적인 인증 관련 기능을 제공한다.

: 당신이 누구인지 증명하는 것

: HTTP는 필요에 따라 고쳐 쓸 수 있는 제어 헤더를 통해, 다른 인증 프로토콜에 맞춰 확장할 수 있는 프레임워크를 제공한다.

요청		인증 정보 X	GET
인증요구	WWW-Authenticate	이름과 비번을 제공하라는 지시의 의미로 401 상태정보와 함께 요청을 반려한다.	401 Unauthorized
인증	Authorization	클라이언트는 인증 알고리즘과 사용자 이름과 비밀번호를 기술한 Authorization 헤더를 보낸다	GET
성공	Authentication-Info	인증 정보가 정확하면 서버는 문서와 함께 응답한다.	200 OK

: 웹 서버는 기밀문서를 보안 영역(realm) 그룹으로 나눈다. 보안 영역은 저마다 다른 사용자 권한을 요구한다.

: 가장 잘 알려진 HTTP 인증 규약이며 모든 주요 클라이언트와 서버에 기본 인증이 구현되어 있다.

기본 인증에서 웹 서버는 클라이언트의 요청을 거부하고 유효한 사용자 이름과 비밀번호를 요구할 수 있다.

: HTTP 기본 인증은 사용자 이름과 비밀번호를 콜론으로 합치고 base-64 인코딩 메서드를 사용해 인코딩 한다.

Base-64 인코딩: 8비트 바이트로 이루어져 있는 시퀀스를 6비트 덩어리 시퀀스로 변환하는 것. 각 6비트 조각은 대부분 문자와 숫자로 이루어진 특별한 64개 문자 중에서 선택된다.

기본 Authorization 헤더 생성하기 과정

base-64는 어렵지 않게 사용자 이름과 비밀번호 문자를 섞을 수 있기 때문에, 이름과 비밀번호가 노출되는 문제를 예방하는 데 도움을 준다.

: 중개 프락시 서버를 통해 인증할 수도 있다. 사용자들이 서버나 LAN이나 무선 네트워크에 접근하기 전에 프락시 서버를 거치게 하여 사용자를 인증할 수 있다.

프락시 서버에서 접근 정책을 중앙 관리할 수 있기 때문에 통합적인 접근 제어를 하기 위해 프락시 서버를 사용하면 좋다.

기본 인증은 사용자 이름과 비밀번호를 쉽게 디코딩할 수 있는 형식으로 네트워크에 전송한다. base-64로 인코딩 된 절차를 반대로 수행하면 어렵지 않게 디코딩 할 수 있다. 문제가 된다면, 모든 HTTP 트랜잭션을 SSL 암호화 채널을 통해 보내거나, 보안이 더 강화된 다이제스트 인증 같은 프로토콜을 사용하는 것이 좋다.
기본 인증은 재전송 공격을 예방하기 위한 어떤 일도 하지 않는다.
악의를 가진 누군가가 무료 인터넷 이메일 같은 사이트에서 사용자 이름과 비밀번호 문자열을 그대로 캡처하고, 동일한 사용자 이름과 비밀번호로 중요한 온랑니 은행 사이트에 접근할 수도 있다.
메시지의 인증 헤더를 건드리지 않지만, 중간에 프락시나 중개자가 개입하는 경우 기본 인증의 정상적인 동작을 보장하지 않는다.
가짜 서버의 위장에 취약하다.

기본 인증은 일반적인 환경에서 개인화나 접근을 제어하는데 편리하며, 다른 사람이 보지 않기를 원하기는 하지만 보더라도 치명적이지 않은 경우엔 유용하다.