[트러블 슈팅] 로그인 방식과 보안에 대한 고찰 - 1 (세션 로그인 방식과 jwt 토큰 발급 방식)

실제로 운영할 서버를 만들면서, 보안에 대해서도 신경을 굉장히 많이 쓰게 되었다.

XSS 공격과 CSRF 공격을 막기 위해 공부한 것들을 정리하겠다.

 

우선 세션 로그인 방식과 jwt 토큰 발급 방식에 대해 비교해 보도록 하겠다.

 

세션 로그인 방식과 jwt 토큰을 활용한 로그인 방식

두 가지 중 우리는 프로젝트에 어떤 로그인 방식을 도입해야 할까?

 

우선 세션 로그인 방식이 뭔지부터 알아보도록 하자

 

세션 로그인 방식

1. 사용자가 로그인을 시도한다.
2. 데이터베이스에서 인증 정보를 확인한다.
3. 세션 id를 발급하고 해당 정보를 세션 저장소에 저장한다.
4. 세션 id를 쿠키로 설정해서 프론트엔드에 반환한다.

세션 id가 쿠키에 설정된 이후 플로우

1. 사용자가 요청을 보낸다.
2. 쿠키에 세션 id 정보가 포함돼 있다.
3. 서버의 세션 저장소에서 세션 id를 찾고 세션 id가 존재한다면, 들어온 요청을 수행해서 반환한다.

대략적으로 이러한 흐름이다.

 

이제 장단점을 살펴보자

 

세션 로그인 방식의 장점

• 사용자의 인증 정보를 모두 서버에서 관리하기에 보안에 용이하다.
• 쿠키의 만료기간이 끝날 때까지 사용자는 로그인을 다시 하지 않아도 된다.
• http only와 secure 등의 옵션을 추가하면 XSS 공격으로부터 안전하다.

세션 로그인 방식의 단점

• 다중 서버 환경에서 세션 정보의 불일치 문제가 발생할 수 있다. (통합 인증 문제)
• 쿠키에 인증 정보를 저장하기 때문에 CSRF 공격에 취약하다.
• 사용자가 많아질 수록 세션 저장소의 크기가 커진다.

이러한 장단점이 존재한다.

 

그럼 이러한 단점들은 어떻게 극복할 수 있을까?

세션 로그인의 단점을 극복해 보도록 하자

• 먼저 첫 번째 다중 서버 환경에서 세션 정보의 불일치 문제 해결 방법
  1. Sticky Session
     • 한 번 요청이 들어간 서버에 계속해서 요청을 넣는 방식이다.
     • 한 서버에 부하가 몰릴 수도 있다는 단점이 존재한다.
  2. 별도의 세션 저장소 설정
     • redis나 memcached 같은 캐시를 사용해서 별도의 세션 저장소에 모든 세션 정보를 저장하는 방법이다.
• CSRF 공격 대응법
  • 서버에서 CSRF 토큰을 발급하고 이를 사용하면 된다.

이러한 대응법이 존재한다. 그러나 세션 저장소의 크기가 커지는 것은 마땅한 대응책이 존재하지 않는다.

 

그래서 나타난 것이 바로 JWT 토큰이다.

 

jwt 토큰은 클라이언트 측에 인증 정보를 저장하기 때문에, 별도의 세션 저장소를 만들 필요가 없다.

이 말은 확장성에 유리하다는 의미이고, 최근 유행하는 MSA 아키텍쳐에서 뛰어난 강점을 보인다.

 

MSA 아키텍쳐가 유행하며, JWT 토큰의 로그인 방식이 급 부상하기 시작했다.

 

로그인 흐름부터 알아보도록 하자

 

JWT 토큰 로그인 방식

1. 사용자가 로그인을 시도한다.
2. 데이터베이스에서 인증 정보를 확인한다.
3. 액세스 토큰과 리프레시 토큰을 발급하여 반환한다.

로그인 성공 이후 플로우

1. 인증이 필요한 모든 요청 헤더에 액세스 토큰을 추가한다.
2. 액세스 토큰을 복호화하며 검증을 시도한다.
3. 검증에 통과했다면, 해당 요청의 반환 값을 반환한다.

토큰이 만료된 경우

1. 액세스 토큰의 만료 시간이 지나 토큰이 만료됐다.
2. 검증에 실패하고, 401 에러가 반환된다.
3. 프론트에선 해당 응답을 받고 사용자가 눈치채지 못하게 리프레시 토큰을 활용하여 토큰을 재발급한다.
4. 이후 재발급 받은 액세스 토큰을 활용하여 다시 요청을 보낸다.

이러한 흐름이다.

 

이제 장단점을 살펴보도록 하자.

 

JWT 토큰 로그인 방식의 장점

1. 앞에서 말했듯이 별도의 인증 정보 저장소가 필요하지 않다.
2. 인증 정보를 클라이언트 측에서 관리하니 확장성에 유리하다.

JWT 토큰 로그인 방식의 단점

• XSS 공격과 CSRF 공격에 대비하기 위해 준비해야 할 것이 많다. (보안에 상대적으로 취약함)
• JWT 토큰은 base64로 인코딩 되었기에, 누구나 디코드가 가능하다. 즉, 토큰에 민감한 정보를 담으면 안 된다.
• 리프레시 토큰을 저장하기 위한 별도의 저장소가 필요하다.
  (리프레시 토큰을 저장하는 것에서 세션 로그인 방식과 도긴개긴인 거 같은 느낌이 들기도 한다.)

jwt 토큰을 사용할 때 XSS 공격과 CSRF 공격을 막기 위해 어떤 조치를 취해야 하는지는 다음 포스트에 정리하도록 하겠다.

 

결론

자 로그인 방식의 장단점에 대해 살펴 보았다. 우리는 어떤 로그인 방식을 선택할 것인가.

 

우리 프로젝트의 특징을 살펴보자, 우선 ASG를 적용하여 동적으로 서버의 개수가 변하도록 만들 것이다.

추후, 지원자 평가 등의 기능을 추가하며 더 확장을 시킬 가능성이 존재한다.

 

따라서 우리는 별도의 저장소가 필요하지 않고 확장에 용이한 JWT 토큰 로그인 방식을 채택하도록 하겠다.

 

이제 이와 관련한 보안 조치는 다음 포스트에 정리하겠다.