개발을 하는데 로그인한 유저를 어떻게 관리를 해야할까?
주로 쓰는 방식인 세션과 JWT를 알기 전에 쿠키에 대한 개념까지 같이 정리해보았다.
쿠키
클라이언트 (브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일
- 사용자 인증이 유요한 시간을 명시 가능 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지됨
- 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조
- 클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있음, 하나의 쿠키 값은 4KB까지 저장
Response Header에Set-Cookie속성을 사용하면 클라이언트에 쿠키 만들 수 있음- 쿠키는 사용자가 따로 요청하지 않아도 브라우저가
Request시에Request Header를 넣어서 자동으로 서버에 전송
종류
- 영속 쿠키 : 해당 날짜까지 유지
- 세션 쿠키 : 브라우저 종료시 까지만 유지
구성 요소
- 이름 : 각각의 쿠키를 구별하는데 사용되는 이름
- 값 : 쿠키의 이름과 관련된 값
- 유효시간 : 쿠키의 유지 시간
- 도메인 : 쿠키를 전송할 도메인
- 경로 : 쿠키를 전송할 요청 경로
동작 방식
- 클라이언트가 페이지 요청
- 서버에서 쿠키 생성
- HTTP 헤더에 쿠키를 포함시켜 응답
- 브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관
- 서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답
EX)
- 장바구니 기능
- “아이디와 비밀번호 저장하시겠습니까?”
- “오늘 더 이상 이 창을 보지 않음“
세션
일종의 저장공간
서버에 접속한 클라이언트 숫자만큼 세션이 생성된다.
서버의 부담을 주기 때문에 이를 보완하기 위해서 토큰을 이용한 로그인 처리도 많이 사용하는 추세
세션은 클라이언트만의 개인공간이기 때문에 개인 세션 공간에 그 사용자 만의 고유정보를 집어넣고 필요할 때마다 꺼내서 사용하는데 사용합니다.
Ex) 로그인이 성공한 이후에 로그인한 계정의 정보를 집어넣는 식으로 사용
세션이 클라이언트 한명의 개인공간이라면 한개의 웹페이지에 한개의 컴퓨터로 동시에 로그인 불가능하다는 소리지만 같은 브라우저 내의 새로운 탭으로는 동시에 로그인이 불가능하지만 아예 실행중인 브라우저와 다른 브라우저를 실행시켜 로그인하면 되는 이유가 서버는 브라우저 단위로 접속한 클라이언트를 확인하기 때문입니다.
단점
- 인증 방식을 사용할 때 중앙 세션 관리 시스템에서 하나의 문제가 시스템 전체로 확산됨.
- 사용자가 많아짐에 따라 세션
DB와 서버를 확장해야 함
* 세션 정보가A와B의DB로 나뉘어졌을때 세션A에 저장되어 있는데 request를 보낼 때A에서 통신하도록 추가적인 기술 필요
웹 클라이언트 저장 공간
웹 스토리지
세션 스토리지
session cookies와 비슷- 세션이 종료되면 모두 삭제 됨
- 쿠키와 다르게 서버에서 접근 불가능
- 클라이언트에서 스토리지의 값을 꺼내서 서버에 전달해주어야 함
- 5~10 MB
로컬 스토리지
- 쿠키와 다르게 반영구적으로 저장 가능
- 세션 스토리지와 마찬가지로 서버에서 접근 불가능
- 클라이언트에서 값에 접근해 서버에 전달하는 과정 필요
쿠키
JWT
세션의 단점을 어느정도 해결할 수 있는 기술
구성
.을 기준으로 구분되어 header, payload, signature로 구성
암호화되지 않아서 누구나 확인할 수 있기 때문에 JWT에 담으면 안된다.
- header : typ와 alg라는 정보가 존재하는데 typ의 값은 JWT이고 alg signature를 해싱하기 위한 알고리즘
{
"alg" : "HS256",
"typ" : JWT
}- payload : 토큰에서 사용할 조각들인 클레임이 존재
토큰의 목적에 따라 클레임이 달라진다.
registered claim에 토큰 만료시간, 토큰 발급 날짜 등을 작성 - signature : 토큰을 인코딩하거나 유효성 검사를 할 때 필요한 암호화 코드
동작 방식
- JWT는 일종의 확인서
- 우리가 어떤 웹사이트에 로그인해서 성공적으로 Authentication이 이루어지면 서버는 사인된 확인서(JWT)를 제공
- 앞으로 요청 때마다 JWT를 서버에게 같이 보여주면 권한을 확인받는 것
- 서버는 JWT만 확인해 Authorization하기 때문에 세션 DB에 저장할 필요 없음
저장 위치
- 브라우저 저장소에 저장하는 방식
* 로컬 브라우저 or 세션 스토리지 같은 브라우저 저장소에 JWT 저장하면 스크립트 공격에 취약 - 쿠키 저장 방식
*http-only를 사용한다면 HTTPS로만 쿠키가 전달되기 때문에 보안 강화, CSRF 문제에 대해서는 CSURF 같은 라이브러리를 사용함으로 해결
🔎 세션 vs JWT
-
세션방식에서 서버는 로그인 된 유저의 정보를 모두 저장하고 있어서 유저들의 통제가 JWT보다 비교적 쉽다. 만약 PC와 모바일기기에서 동시 접근하는 것을 막고 싶을 때 강제 로그아웃 시키는 기능은 세션을 통해 구현이 가능하다.
-
JWT를 서버가 발급하고나면JWT를 관리하지 않는다. 오직JWT를 받았을 때JWT가 유효한 것인지만 확인하기 때문에 서버 자원과 비용을 절감할 수 있다. 그러나JWT가 수명이 길어서 제 3자에게 탈취당할 경우가 발생할 수 있다.
* 이를 보완한 방법 중 하나로access token&refresh token방식이 있는데 두개의 토큰 모두JWT이다.
access token & refresh token
access token&refresh token방식은 토큰 들에 유효기간을 주어서 보안을 강화시킨 것이다.Access token은 유효시간이 짧은 토큰이고,refresh token은access token보다 유효기간이 긴 토큰이다.
- 사용자가 로그인을 하면 서버로부터
access token,refresh token2개의 토큰을 받는다. 이때 서버는refresh token을 안전한 저장소에 저장한다. - 서버로부터 받은
access token의 유효 기간이 지나지 않은 경우 사용자가 어떤 요청을 보낼 때access token을 함께 보내고 서버는 유효한지 확인 후 응답 - 서버로부터 받은
access token의 유효 기간이 지난 경우 사용자는refresh token과 함께 요청을 보내고, 저장소에 저장되어 있던refresh token과 비교한 후에 유효하다면 새로운access token과 응답을 함께 보낸다.
그동안은 스프링 시큐리티에서 지원해주는 세션 관리를 이용하였는데 로그인 유저가 많고, 서비스의 사이즈가 컸을 때는 다른 WAS의 로그인 사용자를 구별하기의 어려움이 있을 것 같아 access token과 refresh token을 사용하는 JWT가 대규모 서비스에는 맞는 전략인 것 같다.
출처 : Guide to Spring Session | Baeldung
Java-Spring 로그인 Seesion 처리
쿠키와 세션에서 세션은 어디에 저장되는가? - 현구막 기술 블로그
Spring Boot Session과 Cache의 기본 저장소 !
