인증 ( 세션, 쿠키, 로컬 )

세션 기반 인증

세션은 로그인에 성공한 유저가 서비스를 사용하는 동안 저장하고 있는 유저 정보입니다. 서버는 세션을 생성하고 나서 세션을 데이터베이스에 저장하고, 이후 사용자의 요청에 포함된 세션 정보가 세션 DB에 저장되어 있는 지 확인합니다. 브라우저에는 데이터를 저장할 수 있는 공간이 있습니다.

- 현재 열려있는 브라우저을 닫거나 새로운 탭 또는 창을 열면 데이터가 삭제되는 세션 저장소

- 창이 닫히더라도 데이터가 남아 있는 로컬 저장소, 

- 간단한 데이터를 저장할 수 있는 쿠키가 있습니다.

 

세션방식의 단점은 악의적인 공격자가 브라우저에 저장된 데이터를 탈취할 수 있다는 것입니다. 비록 세션을 알 수 없는 문자열로 만들었다고해도, http는 보안에 취약하기 때문에 중간에 전달되는 데이터 역시 가로챌 수 있습니다. 이렇게 탈취된 세션을 이용하면 마치 해당 사용자인 것처럼 서버에 접근할 수 있게 됩니다. 이를 방지하기 위해 https로 암호화된 통신을 하고 세션에 유효시간을 정해둡니다. 유효시간이 만료된 세션인 경우 다시 로그인을 유도하게 합니다. 유효시간은 서비스 사용자가 사용에 불편함이 없는 적당한 시간으로 정해야 합니다

 

세션은 서버의 저장소에 저장되고 빠른 응답을 위해 메모리에 상주시키는 경우가 많습니다. 이로 인해 서비스에 사용자가 몰렸을 경우 매 요청마다 세션을 확인해야 하므로 DB에 많은 부하를 일으키게 되고 메모리 부족으로 서비스 장애가 발생할 수도 있습니다. 클라우드를 이용하면 서버와 DB를 유연하게 증설할 수 있다고 하지만 그 시간동안에 서비스 장애를 겪을 수도 있습니다. Redis와 같은 인프라를 이용하여 메모리에 상주하는 세션을 좀 더 빠르게 처리하도록 하는 방법을 사용하기도 합니다.

또한 서비스가 여러 도메인으로 나누어져 있는 경우 CORS 문제로 인해 도메인간 세션을 공유하도록 하기 위한 처리가 번거롭습니다.

 

토큰 기반 인증

세션이 사용자 인증 정보를 서버에 저장하는 방식인 반면, 토큰은 사용자가 로그인 했을 때 서버에서 토큰을 생성해서 전달하고 따로 저장소에 저장하지 않는 방식입니다. 이후 요청에 대해 클라이언트가 전달한 토큰에 대해 검증만 수행합니다. 이렇게 하기 위해서는 당연히 특정한 검증 방식이 필요한데 JWT를 많이 사용합니다.

토큰 기반 인증을 이용하면 세션과 같이 상태를 관리할 필요가 없어 어느 도메인의 서비스로 보내더라도 같은 인증을 수행할 수 있게 됩니다. 이를 확장하면 Facebook, Google 계정으로 다른 서비스에 로그인을 할 수 있는 OAuth를 구현할 수 있습니다. 또한 토큰 기반 인증 방식은 세션 저장소가 서버에 필요하지 않기 때문에 세션기반 방식에서 발생한 문제가 줄어듭니다.

 

하지만 토큰만 가로챈다면 문제가 발생할수 있어서 리플레시 주기를 짧게 해줘야 한다.

JWT 관련

https://wikidocs.net/158629