[Login] SSR과 JWT, Token

SSR(Server Side Randering)

Q : 서버 사이드 렌더링을 왜 쓸까?

A: 서버 사이드 렌더링을 쓰는 목적은 크게 "검색 엔진 최적화"와 "빠른 페이지 렌더링"입니다. 검색 엔진 최적화란 구글, 네이버와 같은 검색 사이트에서 검색했을 때 결과가 사용자에게 많이 노출될 수 있도록 최적화 하는 기법입니다. 특히, SNS에서 링크를 공유했을 때 해당 웹 사이트의 정보를 이미지와 설명으로 표시해주는 OG(Open Graph) Tag를 페이지 별로 적용하기 위해서는 서버 사이드 렌더링이 효율적입니다.

Session과 Token의 차이점

1.  세션과 토큰을 사용하는 이유

유저가 로그인을 시도할 때 서버상에서 일치하는 유저 정보를 찾았다면 인증 확인의 표시로 서버에서 클라이언트로 세션이나 토큰을 발급/전달함. 그럼 웹 브라우저에서 받은 세션과 토큰의 정보를 받아서 가지고있다가, 새로운 Request를 보낼 때 마다 내가 인가된 사용자!라는 표시로 해당 세션/토큰을 항상 같이 넣어보냄

 

2. 세션과 토큰의 차이점

ㄱ. 보관

세션은 서버측에서 저장/관리함

토큰은 서버측에는 저장하지않고 클라이언트의 웹 브라우저(쿠키)에 저장 됨

( 그래서 공격에 노출될 가능성이 크기때문에 민감정보를 담지 않고, 유효기간을 짧게 설정함 )

 

ㄴ. 서버분산/클러스터 환경에서의 문제

서버를 다중화 하여 구성한경우, 클라이언트가 request 때마다 접속한 서버가 달라지게 되면 저장된 session 정보가 없기때문에 매번 로그인을 다시 해야함( 이런 세션의 단점을 해결하기위해 sticky session이라는 방안이 있지만, 이경우 처음 지정받은 서버가 터지면 recovery 될때까지 장애포인트가 될 수 있음)

 

3. 동작 방식

ㄱ. 세션

클라이언트가 로그인 Request 를 보냄

서버에서 세션을 생성/저장하여 response 데이터에 cookie에 session_id를 전달함

클라이언트는 Request 할때마다 쿠키 session id를 같이 보냄

서버는 해당 내용을 확인하여 성공/실패여부를 전달함

 

ㄴ. 토큰

클라이언트가 로그인 Request 를 보냄

서버에서 가지고있는 secret key로 토큰을 생성하여 토큰을 전달함

클라이언트는 Request 할때마다 토큰을 같이 보냄

서버는 받은 토큰을 secret key로 풀어서 user정보를 확인하고 성공/실패여부를 전달함*)

가장 큰 차이는 관리 주체의 차이 세션(서버), 토큰(클라이언트)

토큰의 경우 세션에 대한 정보를 서버에 저장하지않아서 중복 로그인 처리같은 기능은 세션방식에서만 구현을 할 수 있음추가 )

 

JW의 access token & refresh token
- access token & refresh token 방식은 토큰들에 유효기간을 주어서 보안성을 강화함
- access token은 유효기간이 짧은 토큰이고, refresh token은 access token보다 유효기간이 긴 토큰

1. 사용자가 로그인을 하면 서버로부터 access token, refresh token 2개의 토큰을 받는다. 이때 서버는 refresh token을 안전한 저장소에 저장한다.
2. 서버로부터 받은 access token의 유효 기간이 지나지 않은 경우 사용자가 어떤 요청을 보낼 때 access token을 함께 보내고 서버는 유효한 지 확인 후 응답을 보낸다.
3. 서버로부터 받은 access token의 유효 기간이 지난 경우 사용자는 refresh token과 함께 요청을 보내고, 저장소에 저장되어 있던 refresh token과 비교한 후에 유효하다면 새로운 access token과 응답을 함께 보낸다.

      ㄴ 이 경우 Refresh token의 유효기간동안은 다시 로그인해서 토큰을 발급받을 필요가 없다