[WEB] Authentication (1) 세션과 쿠키

Authentication

우선 Authentication이 뭔지부터 알아봅시다.

여러분이 어떤 서비스를 이용할 때, 아이디와 비밀번호를 입력하고 로그인을 한 경험이 있으실 겁니다.

이것이 바로 여러분이 서버로 부터 인증을 받은 겁니다.

인증을 받았기 때문에 로그인한 사용자가 할 수 있는 여러 동작들에 대해서 허락을 맡게 된거죠.

유저 입장에서는 아이디와 비밀번호를 입력하여 로그인을 하더라도 서버에서는 이를 구현하는 방법이 굉장히 다양합니다.

 

 

stateless한 HTTP

기본적으로 서버와 클라이언트는 HTTP를 통해 통신을 합니다.

하지만 HTTP는 connectionless하기 때문에 클라이언트의 요청에 대해서 응답을 하고 바로 연결을 끊어버리게 됩니다.

그렇기 때문에 HTTP는 stateless하다고 하는데 클라이언트의 이전 상태를 알 수가 없습니다.

그 말인즉, 클라이언트에서 로그인을 하고 해당 유저의 정보를 확인했어도 다음 요청에 대해서는 다시 인증이 된 사용자의 요청인지 구분을 할 수가 없다는 말 입니다.

HTTP의 이러한 특징 때문에 새로운 요청에 대해서 인증을 해야할 필요가 생깁니다.

 

쿠키와 세션

이러한 문제를 해결하기 위해서 여러 방법이 있지만 이번 포스팅에서는 세션과 쿠키에 대해서 알아보도록 하겠습니다.

	쿠키	세션
정의	클라이언트인 웹 브라우저 로컬에 키-값 형태로 저장하는 작은 데이터 파일	일정 시간 동안 같은 사용자, 브라우저로 부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지하는 기술
만료시점	만료 시점을 명시 가능, 브라우저가 종료되더라도 유효시간이 남아있으면 유지	브라우저가 종료될 때 까지 유지(쿠키도 여러 종류가 있고 만료 시점이 다름. 뒤에서 자세히 다룰 예정)
저장위치	클라이언트에 파일로 저장	서버에 저장
용량제한	한 도메인 당 20개, 모든 도메인에 대해 300개 제한(쿠키는 모든 request와 response에 대해 header에 들어가게 되므로 용량 제한이 필요)	정해진 용량 제한은 없으나 서버 메모리에 저장하기 때문에 많아질 경우 성능 저하
사용사례	자동 로그인, '24시간 동안 열지 않음' 팝업, 장바구니	로그인 상태 유지

 

Authentication

쿠키와 세션에 대해 알아보았으니 이를 통해 어떻게 인증을 하는지 알아봅시다.

먼저 처음 접속하는 상황입니다.

로그인 시

세션 저장소를 무엇으로 사용할지에 대한 정답은 없습니다.

위 그림에서는 DB와 분리했지만 DB에 table로서 저장하기도 하고, redis 등 캐시를 사용하기도 합니다.

각각에 대해서 좀 더 자세하게 알아봅시다.

1. 로그인 요청

   사용자는 로그인 화면에서 적절한 아이디와 패스워드를 입력하고 로그인 버튼을 누르게 됩니다.

   일반적으로 HTTP body에 해당 정보가 담겨 서버로 전송됩니다.

2. DB 조회

   넘어온 정보가 유효한 사용자인지 검사하기 위해서 DB를 조회합니다.

   지금은 당연히 유효한 사용자라는 가정하에 진행되고 있습니다.

3. 세션 생성

   해당 사용자의 고유한 ID값을 부여하여 세션 저장소에 저장한 후, Session ID를 발행합니다.

   이 때 세션 유지 시간도 설정할 수 있는데 이는 서버에 요청을 보내지 않으며 유지할 수 있는 최대 시간을 말합니다.

4. Session ID 응답

   세션 저장소에서 발급받은 Session ID를 쿠키에 저장하여 클라이언트로 응답합니다.

   쿠키에 저장하는 방식에 대해서는 아래에서 좀 더 자세히 다루도록 하겠습니다.

 

 

다음으로는 로그인이 된 후의 상황입니다.

로그인 후

1. 요청

   굉장히 다양한 요청이 있을 수 있습니다. 페이지 이동, 글쓰기, 댓글쓰기 등등 말이죠.

   요청이 서버로 전송될 때 쿠키는 자동으로 함께 전송됩니다.

2. 쿠키의 Session ID 검증

   넘어온 요청에 있는 쿠키의 Session ID가 유효한지 확인합니다.

3. 응답

   인증이 완료되었므로 사용자의 요청에 대해 응답합니다.

 

 

쿠키 설정 방법

마지막으로 쿠키 설정 방법에 대해서 알아보겠습니다.

설정하기 위해서 Set-Cookie HTTP 응답 헤더를 사용합니다.

해당 헤더에 들어갈 수 있는 인자들을 살펴봅시다.

 

name-value

위에서도 여러 번 언급했지만 쿠키는 특정 정보를 저장해야 합니다.

따라서 이를 name-value 형태로 (key-value와 유사) 저장합니다.

 

Expires (Optional)

쿠키의 만료시간을 Date로 설정할 수 있습니다.

해당 값이 설정되지 않으면 세션쿠키 라고 해서 브라우저가 종료될 때 함께 파기됩니다.

 

Max-Age (Optional)

쿠키의 만료시간을 시간으로 설정할 수 있습니다.

Expires 를 통해 끝나는 시각을 설정한다면 Max-Age 는 쿠키의 지속시간을 설정한다는 점에서 차이가 있습니다.

ie6, ie7, ie8 등 오래된 브라우저는 이를 지원하지 않을 수도 있습니다.

만일 Expires 와 같이 지정된다면 Max-Age 가 더 우선순위가 높습니다.

 

Domain (Optional)

쿠키가 적용되어야 하는 호스트를 지정합니다.

지정되어 있지 않으면 현재 문서 URI를 기준으로 적용하고 서브 도메인을 포함하지 않습니다.

도메인을 지정되면 서브도메인들은 항상 포함됩니다.

 

Path (Optional)

쿠키 헤더를 보내기 전에 요청된 리소스에 있어야하는 URL 경로를 나타냅니다.

경로를 지정하지 않으면 Set-Cookie 헤더와 연결된 리소스의 경로로 간주됩니다.

 

Secure (Optional)

이를 설정한 쿠키들은 HTTPS 프로토콜을 통해 통신이 이루어질 때만 사용가능합니다.

 

HttpOnly (Optional)

XSS (Cross-Site Scripting)에 대한 공격을 완화하기 위해 XMLHttpRequest 및 Request API 속성, JavaScript를 통해 HTTP 전용 쿠키에 액세스 할 수 없습니다.

 

SameSite (Optional)

서로 다른 도메인 간의 쿠키 전송에 대한 보안을 설정합니다.

Strict 나 Lax, None이 가능합니다.

Strict 는 서로 다른 도메인에 대해 아예 전송이 불가능하여 CSRF 를 완벽히 방지할 수 있으나 사용자 편의성을 해치게 됩니다.

Lax는 HTTP get method, a href, link href 등 예외를 둡니다.

None은 모든 경우 쿠키 전송이 가능합니다.

 

예시는 다음과 같습니다.

Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/