12.1 인증

인증은 내가 누구인지 증명하는 것이다. (비밀번호 등)

12.1.1 HTTP의 인증요구/응답 프레임워크

웹 애플리케이션이 HTTP 요청 메시지를 받으면, 서버는 요청을 처리하는 대신 현재 사용자가 누구인지를 알 수 있게 비밀번호 같이 개인정보를 요구하는 인증요구로 응답할 수 있다.
사용자가 다시 요청을 보낼 때 인증정보(이름, 비번)을 같이 보내야 하고 인증정보가 틀리면 서버는 인증요구를 다시 보내거나 에러를 낼 수 있다.
인증정보가 맞으면 요청이 처리된다.

요청 -> 인증요구(401) -> 인증 -> 성공(200)

12.1.2 인증 프로토콜과 헤더

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

• 공식적인 HTTP 인증 프로토콜

  • 기본 인증
  • 다이제스트 인증(13장)

현대에 HTTP 인증요구 /응답 프로토콜을 사용하는 인증 프로토콜에는 OAuth가 있다.

네가지 인증단계

1. 요청
2. 인증요구
   사용자에게 401 상태코드와 함께 WWW-Authenticate 헤더를 기술해서 어디서 어떻게 인증할지 설명한다.
3. 인증
   클라이언트가 서버로 인증하려면 인코딩된 비밀번호와 그 외 인증 파라미터들을 Authorization 헤더에 담아서 요청을 다시 보낸다.
4. 성공

12.1.3 보안영역

보안 영역은 각각 다른 사용자 권한을 요구한다.

12.2 기본 인증

기본 인증은 가장 잘 알려진 HTTP 인증 규약이다.

웹서버는 클라이언트 요청을 거부하고 유효한 사용자 이름과 비밀번호를 요구할 수 있다. 서버는 200 대신 401 상태 코드와 함께 클라이언트가 접근하려 했던 보안 영역을 WWW-Authenticate에 기술해서 응답하여 인증요구를 시작한다.

브라우저는 사용자로부터 사용자 이름과 비밀번호를 입력받아 Authorization요청 헤더 안에 암호화해서 다시 서버로 보낸다.

12.2.2 Base-64 사용자이름/ 비밀번호 인코딩

사용자 이름과 비밀번호를 콜론으로 이어 합치고 base-64인코딩 메서드를 사용해 인코딩한다.
base-64인코딩은 8비트 바이트로 이루어져있는 시퀀스를 6비트 덩어리의 시퀀스로 변환한다. 각 6비트 조각은 대부분 문자와 숫자로 이루어진 특별한 64개의 문자 중에서 선택된다.

12.2.3 프락시 인증

중개 프락시 서버를 통해 인증할 수도 있다.
프락시 서버에서 접근 정책을 중앙 관리 할 수 있기 때문에 회사 리소스 전체에 대해 통합적인 접근 제어를 하기 유리하다. ( 회사의 서버나 Lan이나 무선네트워크에 접근하기 전에 프락시 서버를 거치게 하여 사용자를 인증한다.)

프락시 인증으로 사용자를 식별하는 것은 웹 서버의 인증과 헤더와 상태코드만 다르고 절차는 같다.

12.3 기본 인증의 보안 결함

기본 인증은 단순하고 편리하지만 안심할 수는 없다. 기본인증은 악의적이지 않은 누군가가 의도치 않게 리소스에 접근하는 것을 막는 데 사용하거나 SSL 같은 암호기술과 혼용한다.