JWT(Json Web Token)에 대해 이해하기 전에 알고 있으면 좋은 개념들을 먼저 알아보자
세션

유저가 웹 브라우저를 통해 네이버 서버에 www.naver.com라고 적어서 요청을 하면 서버는 해당 주소에 맞는 컨트롤러의 메서드를 찾는다.
그리고 메서드에서 요청에 맞는 html 파일을 응답해 준다. 이때 http header를 단다. 이 header에 쿠키를 만들어서 쿠키에 세션 id를 담아서 준다. 웹 브라우저는 이 세션 id를 받아서 브라우저의 쿠키라는 저장영역에 세션 id가 담긴다. 이는 최초 요청 시에 만들어진다.

두 번째 요청부터는 브라우저가 쿠키에 있는 세션id를 가지고 간다. 두 번째 요청부터는 서버가 세션 id를 생성하지 않고 기존의 세션 id를 그대로 돌려준다.
서버는 세션id를 발급해 줄 때마다 목록을 만든다. 그래서 브라우저가 요청할 때 세션 id가 없다면 새로 만들어주고, 세션 id를 가지고 왔다면 목록과 비교해서 방문한 적이 있는지 알 수 있다.
이 세션id는 다음 상황에서 없어진다.
- 서버에서 세션의 값을 강제로 지울 때
- 사용자가 브라우저를 종료할 때(브라우저의 쿠키 공간에 있는 세션 id가 없어진다.) 이 경우 다시 서버에 방문할 때 세션id를 가지고 가지 않기 때문에 서버 입장에서는 처음 방문하는 것이 되어 새로운 세션id를 만들어준다.
- 일정 시간이 지나면 서버의 세션 값이 지워진다. (보통 30분)
세션은 보통 로그인 요청 시 사용된다.(인증)

클라이언트가 서버에 처음 요청을 하면 서버는 세션이라는 저장소에 세션id를 하나 만든다. 그리고 해당 세션id 만의 저장소가 생긴다.
응답을 해줄 때 헤더에 세션 id를 준다. 그러면 클라이언트 브라우저에 세션id가 저장이 된다. 그리고 클라이언트가 로그인 요청을 하면 서버의 DB에서 로그인 id와 pw를 확인한다. 이 값이 맞으면 세션id만의 저장소에 유저 정보를 저장한다.
그 후 사용자가 인증이 필요한 페이지를 요청하면(유저 정보 페이지라고 가정) 서버는 세션id를 확인한다. 그리고 서버의 세션 저장소에서 일치하는 세션id를 찾고 그 세션 id의 저장소에 값이 있는지 확인한다. 값이 있다면 전에 로그인을 했던 사용자이므로 DB에서 값을 가져와 유저 정보를 돌려준다.
세션의 단점
서버가 동접자를 100명 처리할 수 있다고 할 때, 동접자가 300명이면 서버가 3개 필요하다. 사용자 요청이 들어왔을 때 한 서버가 바쁘면 다른 서버로 갈 수 있다. 이것을 로드 밸런싱이라고 한다.
서버가 A, B, C 3개가 있다고 할 때, 처음 로그인 요청을 B 서버에서 처리하면 B 서버의 세션 영역에 세션이 생성된다. 그리고 다음 요청은 로드 밸련싱이 되어서 C 서버로 요청이 들어갔다고 하면, C 서버 입장에서는 처음 온 사용자가 된다.
보완
세션에 정보를 저장하지 않고 서버들이 한 곳의 DB에 데이터를 저장하게 하고 이 DB를 공유해서 사용하게 하는 방법도 있다. 그런데 DB에서 값을 가져오는 것은 세션에서 값을 가져오는 것보다 느리다. 세션은 메모리에 저장되는데 메모리에서 값을 읽어 오는 것이 훨씬 빠르다. 그래서 DB를 사용하지 않고 메모리(RAM) 공유 서버를 사용한다. 메모리 공유 서버에는 대표적으로 Redis가 있다.
세션의 문제점은 JWT로도 해결이 가능하다.
'Spring Security' 카테고리의 다른 글
[웹 보안] RSA (0) | 2023.03.27 |
---|---|
[웹 보안] TCP (0) | 2023.03.27 |
[OAuth] 네이버 로그인 (0) | 2023.03.27 |
[OAuth] 페이스북 로그인 (0) | 2023.03.26 |
[OAuth] 구글 로그인 및 자동 회원가입 진행 완료 (0) | 2023.03.26 |
JWT(Json Web Token)에 대해 이해하기 전에 알고 있으면 좋은 개념들을 먼저 알아보자
세션

유저가 웹 브라우저를 통해 네이버 서버에 www.naver.com라고 적어서 요청을 하면 서버는 해당 주소에 맞는 컨트롤러의 메서드를 찾는다.
그리고 메서드에서 요청에 맞는 html 파일을 응답해 준다. 이때 http header를 단다. 이 header에 쿠키를 만들어서 쿠키에 세션 id를 담아서 준다. 웹 브라우저는 이 세션 id를 받아서 브라우저의 쿠키라는 저장영역에 세션 id가 담긴다. 이는 최초 요청 시에 만들어진다.

두 번째 요청부터는 브라우저가 쿠키에 있는 세션id를 가지고 간다. 두 번째 요청부터는 서버가 세션 id를 생성하지 않고 기존의 세션 id를 그대로 돌려준다.
서버는 세션id를 발급해 줄 때마다 목록을 만든다. 그래서 브라우저가 요청할 때 세션 id가 없다면 새로 만들어주고, 세션 id를 가지고 왔다면 목록과 비교해서 방문한 적이 있는지 알 수 있다.
이 세션id는 다음 상황에서 없어진다.
- 서버에서 세션의 값을 강제로 지울 때
- 사용자가 브라우저를 종료할 때(브라우저의 쿠키 공간에 있는 세션 id가 없어진다.) 이 경우 다시 서버에 방문할 때 세션id를 가지고 가지 않기 때문에 서버 입장에서는 처음 방문하는 것이 되어 새로운 세션id를 만들어준다.
- 일정 시간이 지나면 서버의 세션 값이 지워진다. (보통 30분)
세션은 보통 로그인 요청 시 사용된다.(인증)

클라이언트가 서버에 처음 요청을 하면 서버는 세션이라는 저장소에 세션id를 하나 만든다. 그리고 해당 세션id 만의 저장소가 생긴다.
응답을 해줄 때 헤더에 세션 id를 준다. 그러면 클라이언트 브라우저에 세션id가 저장이 된다. 그리고 클라이언트가 로그인 요청을 하면 서버의 DB에서 로그인 id와 pw를 확인한다. 이 값이 맞으면 세션id만의 저장소에 유저 정보를 저장한다.
그 후 사용자가 인증이 필요한 페이지를 요청하면(유저 정보 페이지라고 가정) 서버는 세션id를 확인한다. 그리고 서버의 세션 저장소에서 일치하는 세션id를 찾고 그 세션 id의 저장소에 값이 있는지 확인한다. 값이 있다면 전에 로그인을 했던 사용자이므로 DB에서 값을 가져와 유저 정보를 돌려준다.
세션의 단점
서버가 동접자를 100명 처리할 수 있다고 할 때, 동접자가 300명이면 서버가 3개 필요하다. 사용자 요청이 들어왔을 때 한 서버가 바쁘면 다른 서버로 갈 수 있다. 이것을 로드 밸런싱이라고 한다.
서버가 A, B, C 3개가 있다고 할 때, 처음 로그인 요청을 B 서버에서 처리하면 B 서버의 세션 영역에 세션이 생성된다. 그리고 다음 요청은 로드 밸련싱이 되어서 C 서버로 요청이 들어갔다고 하면, C 서버 입장에서는 처음 온 사용자가 된다.
보완
세션에 정보를 저장하지 않고 서버들이 한 곳의 DB에 데이터를 저장하게 하고 이 DB를 공유해서 사용하게 하는 방법도 있다. 그런데 DB에서 값을 가져오는 것은 세션에서 값을 가져오는 것보다 느리다. 세션은 메모리에 저장되는데 메모리에서 값을 읽어 오는 것이 훨씬 빠르다. 그래서 DB를 사용하지 않고 메모리(RAM) 공유 서버를 사용한다. 메모리 공유 서버에는 대표적으로 Redis가 있다.
세션의 문제점은 JWT로도 해결이 가능하다.
'Spring Security' 카테고리의 다른 글
[웹 보안] RSA (0) | 2023.03.27 |
---|---|
[웹 보안] TCP (0) | 2023.03.27 |
[OAuth] 네이버 로그인 (0) | 2023.03.27 |
[OAuth] 페이스북 로그인 (0) | 2023.03.26 |
[OAuth] 구글 로그인 및 자동 회원가입 진행 완료 (0) | 2023.03.26 |