늘

현재 저희 공식팀의 서비스는 지식 공유 게시판(약간 stackoverflow느낌)의 웹 플랫폼입니다. 저희 서비스에서는 세션과 토큰 중 어떤 게 적합한 인증방식일지 고민해봤습니다. 일반적인 오해 전통적으로 웹사이트는 쿠키를 사용한 세션 인증을 사용하고 모바일 앱/SPA는 Authorization 헤더와 함께 토큰 인증을 사용하지만 반드시 그런 것은 아니다. Authorization Header와 Cookies는 전송 메커니즘에 관한 것입니다. 토큰과 세션은 기본적으로 서버 측이든 클라이언트 측이든 권한 부여 상태가 처리되는 위치에 관한 것입니다. 예를 들어, 서버는 쿠키를 통해 JWT 토큰을 발행하거나 "Authorization" 헤더에 상태 저장 세션 ID가 제공될 것으로 예상할 수 있다. 출처: ht..

서버가 확장되어 여러 개를 갖게 된다면 요청이 들어올 때마다 로드밸런싱을 통해 부하를 나눌 수 있다. 이때 세션을 사용하면 A라는 서버로 처음에 로그인을 해서 세션 ID가 만들어지고 로그인을 성공한다. 하지만 사용자가 다시 요청을 보낼 때 이번엔 로드밸런싱에 의해 B 서버로 갔다면 B서버에는 사용자의 세션ID가 없으므로 다시 로그인을 시도하라는 요청이 올 수 있다. 이러한 세션과 로드밸런싱의 문제를 해결하기 위해 sticky session이 있다. sticky session 처음 로그인했을 때, 갔던 서버에서 세션 ID를 만들고 로그인이 성공하면 그 회원의 요청은 해당 서버로만 가도록 하는 것이다. 즉, 세션이 만들어진 서버로만 요청이 가는 것이다. 해당 방식은 cookie를 사용하는 방식으로 구현할 수..

HTTP의 특징 connectionless, stateless connectionless는 클라이언트에서 http request를 서버에 보내면, 서버는 알맞은 http response를 보내고 접속을 끊는 특성이 있다. 왜냐하면 여러 클라이언트와 통신을 하려면 한 커넥션이 오래 물고 있으면 성능에 좋지 않기 때문이다. 하지만 매번 연결을 끊고 다시 생성하는 비용도 만만치 않아서 (HTTP1.1에서) keep-alive를 통해서 timeout, max번 connection을 재활용하기도 한다. stateless는 통신이 끝나면 상태를 유지하지 않는 특징이다. 로그인을 성공하고 다음에 글을 적으려고 하면 다시 인증을 해야 한다. 쿠키 HTTP는 connectionless, stateless한 성격을 가진다..

Jwt와 Session방식의 차이에 대해서 공부했다. 우선 우리가 사용하는 스프링 부트는 Session기반으로 작동되어 있다고 한다. 그래서 평소 자연스럽게 이용했던 세션을 통한 인증 관리가 아닌 이번에는 JWT를 이용하여 회원 인증과 권한을 관리해보려고 한다..! 그전에 잠깐 Session&Cookie 기반 인증방식과 Token(jwt) 기반 인증 방식의 차이를 간단하게 설명해 보겠다. Session & Cookie 유저가 로그인하고 세션이 서버 메모리 상에 저장된다. (서버 단에서 메모리 차지가 클 수 있다.) session Id를 기준으로 정보를 전달한다. 브라우저에 쿠키로 session Id를 저장 -> 쿠키로 보내진다. JWT(Json Web Token) 방식 Header, Payload, Si..