HTTP - (6) 클라이언트 식별과 쿠키, 인증

웹서버는 본인과 통신하는 수많은 클라이언트들의 요청을 처리하기도 하지만, 동시에 클라이언트를 추적해야할 수도 있다.

하지만 HTTP는 익명이며, 요청과 응답으로만 구성되어 있는 프로토콜이다.

요즈음 사이트들은 개인화된 추천을 하거나, 캐시로 결제 데이터를 저장해두어 사용자 정보를 띄우는 등 클라이언트에 대한 정보를 원한다.

HTTP는 사용자를 식별할 수 있는 기능을 어떻게 제공할까?

​

- HTTP 헤더

가장 간단하게 생각해볼 수 있는 것은 HTTP헤더에 사용자 정보를 담아 전달할 수 있도록 하는 것이다.

From (사용자의 이메일 주소를 받음), User-Agent (사용자의 브라우저), Referer (근원 페이지) 등이 있다.

​

- 클라이언트 IP주소

웹서버에서 TCP커넥션을 통해 IP주소를 알아낼 수 있는데, 중요한 것은 클라이언트 IP주소가 바뀌지 않는다는 보장이 있어야한다.

문제는 요즈음 ISP가 IP주소를 동적으로 할당해 고정되지 않는다는 것이다. 또한 보안상 NAT를 사용하는데, 이로 인해 실제 IP주소가 가려진다.

무엇보다도 클라이언트는 사용자가 여러 대를 거느리고 사용할 수 있기 때문에 사용자를 식별할 수 있는 단위가 아니기 쉽다.

이때문에 이 방식은 요즈음 잘 사용하지 않는다.

​

- 사용자 로그인 정보

웹서버는 사용자 이름과 비밀번호로 인증할 것을 요구해서 사용자를 구별하기도 한다.

웹 서버는 사용자가 웹사이트에 처음 접근시, 401 Login Required에러 메시지를 클라이언트로 보내고, 클라이언트는 로그인 화면을 띄운다.

로그인 접속정보가 입력되면 Authorization 헤더에 그 정보를 담아 서버 측으로 전송하게 된다.

브라우저는 이 시점 이후부터 서버의 요청 여부와 상관없이 사용자 이름과 비밀번호를 포함하여 전달하고, 세션동안 식별을 유지할 수 있게 해준다.

​

- fat URL

일부 웹사이트는 URL에 사용자의 상태 정보를 포함할 수 있게 구성해두었다.

사용자가 웹 사이트에 처음 방문하면 유니크한 ID가 생성되고, 그 값을 URL에 서버가 인식할 수 있는 형태로 변환하여 삽입한다.

이 방식 마저도 타인에게 URL을 공유하거나, 사용자가 이탈할 경우 다시 초기화된다던지, 서버가 다시 페이지를 그려내는 부하가 발생한다.

​

- 쿠키

현재에도 가장 널리 이용되고 있는 방식으로, 사용자를 식별하고 세션을 유지하는 용도로 사용된다.

쿠키는 세션 쿠키와 지속 쿠키 두 타입으로 나눌 수 있다. 전자는 브라우저를 닫으면 삭제되지만, 후자는 더 오래 유지된다.

지속 쿠키는 드라이브에 저장되기 떄문에 컴퓨터를 재시작하더라도 남아있고, 주로 잦게 방문하는 사이트에 대한 정보를 담고 있다.

사용자가 최초로 웹사이트에 방문하면 쿠키가 발행되고, 응답 헤더에 담겨 클라이언트로 전송된다.

​

쿠키는 브라우저가 저장하게 되며, 이를 '클라이언트 측 상태'라고 부른다.

브라우저마다 다르지만, 주로 쿠키 생성 시점, 도메인 이름, 쿠키 파기 시점 등을 담고 있다.

브라우저는 수백 수천개의 쿠키를 저장하고 있지만, 정작 서버에서 생성한 쿠키만을 전달한다.

* 웹사이트 광고에서 쿠키를 활용하는 경우, 지속 쿠키를 발행하여 여러 웹사이트를 방문하더라도 동일 도메인 쿠키를 발급한다.

​

쿠키는 Version 0 쿠키와 Version 1 쿠키로 이루어져있다. Version1은 상대적으로 많이 쓰이지 않는다.

가장 최초에 넷스케이프가 쿠키에 대한 명세를 작성했따. Set-Cookie 응답 헤더와 Cookie 요청 헤더를 정의하였다.

Set-Cookie는 이름 = 값을 매핑하여 쿠키의 이름과 값을 저장하도록 지시한다. (expires, domain, path등의 속성을 지님)

​

Version1 쿠키는 좀 더 복잡하며, 모든 브라우저와 서버가 지원하진 않는다.

쿠키별 사용 목적을 설명하는 정보와, expire 주기와 상관없이 브라우저가 닫히면 쿠키가 삭제되는 등의 기능들이 추가되었다.

또한 쿠키 생명 주기를 결정하는 Max-age와 도메인/경로 외에 URL포트 번호로도 쿠키 제어가 가능하게 해준다.

​

쿠키를 캐싱하는 것은 주의해야할 필요가 있다. 다른 사용자 정보를 저장할 수 있어 개인정보가 다른 이에게 노출되지 않도록 유의해야한다.

우선 쿠키를 제외하고 캐시를 해야할 경우엔 Cache control : no-cache="Set-Cookie"를 명시해두기도 한다.

---

사람들은 웹사이트를 통해 개인 정보에 접근하거나 정보를 저장해두기도 한다.

웹에서는 이를 사용자 본인 외에는 조회가 불가능하도록 식별정보를 지녀야하고, 이 식별정보를 검증하는 인증 방식이 필요하다.

​

HTTP는 사용자의 인증을 위해 사용되는 프레임워크를 제공한다.

HTTP 요청을 받을 때, 인증 정보를 요청하는 '인증' 요청으로 응답을 대신 보낼 수 있는데, 클라이언트는 인증정보를 첨부하여 다시 요청을 보낸다.

​

HTTP는 기본 인증과 다이제스트 인증이라는 두 가지 인증 프로토콜이 있다.

기본 인증의 경우, 클라이언트에서 웹서버로 인증 정보 없이 GET 메서드로 요청을 보낸다.

그에 따라 서버는 인증을 요구하는 WWW-Authenticate헤더를 통해 401 Unauthorized 상태코드를 보낸다.

클라이언트는 WWW-Authenticate 헤더에 요구해둔 정보를 담아 Authorization헤더에 담아 Get메서드를 보낸다.

서버는 인증 정보가 정확할 경우 200 OK상태코드로 응답하여 인증이 정상적으로 확인되었음을 노티한다.

​

웹서버는 보안 영역(realm) 그룹으로 나누는데, 각기 다른 사용자 권한을 요구한다.

각 문서마다 범위/영역을 지정하여, 특정 영역에 해당하는 권한 요구를 Realm 지시자로 담아 보낸다.

​

어떤 경우에는 프락시를 통해 인증을 거치도록 구성하기도 한다.

프락시 인증은 웹서버 인증과 헤더/상태코드만 다를 뿐 프로세스 자체는 유사하다. (407 에러코드, Proxy-Authenticate.. 등)

​

다이제스트 인증에 대해서는 다음 글에서 좀 더 상세히 알아보도록 하자!

​

---

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980