회고: JWT를 꼭 써야됐을까??

Choizz·2023년 3월 29일
0

회고

목록 보기
1/4

제가 팀 프로젝트를 했을 때, Spring Security를 사용하여 JWT 토큰을 이용한 인증/인가 방식을 구현했습니다.
그런데, 프로젝트 종료 후 생각해보니 왜 JWT 인증 방식을 사용했는지, 세션 방식을 사용하면 되지 않았는지를 생각하게 됐습니다.
그래서, 이번 포스팅은 JWT에 대해 알아보고, 팀 프로젝트에서 꼭 JWT를 사용했어야 됐는지를 이야기해 보려고 합니다.
결론먼저 말씀 드리면, 꼭 JWT 인증 방식을 사용하지 않아도 됐다.입니다. (저의 생각이 틀릴 수 있습니다!)


우선, JWT 인증 방식에 대해 알아봅시다!

토큰 기반 자격 증명

  • 우선, 토큰은 '입장권'이라고 생각을 하면 됩니다. 서버에서 이 토큰을 보고 인증과 인가를 처리합니다.
  • 입장권이라는 말은 서버에서 사용자 정보를 별도로 관리하지 않는다는 것을 의미합니다. (세션을 사용하지 않는다는 것이죠.)

JWT(Json Web Token)이란?

  • 데이터를 전송하기위해 고안된 인터넷 표준 인증 방식.(공식 사이트)
  • Json 포맷의 토큰 정보를 인코딩 후, 인코딩된 토큰 정보를 시크릿 키로 sign한 메시지를 web token으로 사용합니다.

Access Token, Refresh Token

  • JWT 중 사용자의 자격 증명에 사용되는 토큰입니다.
  • 클라이언트가 처음 로그인 시, access token과 refresh token을 받습니다.
  • 둘 중 자격 증명에 사용되는 것은 access token이지만, 보안을 위해 짧은 유효기간을 갖습니다.
  • refresh token은 access token이 만료될 경우, 새로운 access token을 발급 받는 경우 사용합니다.

장점

  1. stateless하고, 확장에 용이한 애플리케이션을 구현할 때 좋습니다.
    • 클라이언트 측에서 request를 전송할 때마다 토큰을 헤더에 포함시키면 됩니다.
    • 여러 대의 서버를 이용한 서비스에서 하나의 토큰으로 여러 서버에서 인증이 가능합니다.
  2. 토큰이 만료되기 전까지 한 번의 인증만 수행하면 됩니다.
  3. 인증을 담당하는 시스템을 분리시키는 것이 가능합니다.
    • 따로 토큰을 생성하는 서버를 만들거나 할 수 있습니다.
  4. 토큰의 내용물에 사용자의 권한 정보를 포함하는 것이 용이합니다.

단점

  1. 토큰의 디코딩이 쉬워 탈취를 당할 시, 토큰의 정보를 확인할 수 있습니다.(base64로 인코딩)
  2. secret key 탈취 시 토큰을 마음대로 생성이 가능합니다.
  3. 토큰의 길이가 길어지면 네트워크에 부하를 줄 수 있습니다.
    • 정보가 많을수록 토큰의 길이가 길어집니다.
  4. 토큰은 자동으로 삭제되지 않기 때문에, 토큰 만료시간(짧게)을 반드시 추가해야 합니다.
  5. refresh token 탈취 시 access token을 발급받을 수 있기 때문에 문제가 될 수 있습니다.

팀 프로젝트에서 JWT를 사용한 이유

그렇다면, 저는 왜 JWT 방식을 썼을까요??

  • 답은 간단합니다. 부트캠프에서 JWT를 배웠기 때문이죠.
  • 프로젝트 개발 당시 별 생각없이 썼습니다..

꼭 JWT 인증 방식을 사용해야 했나?

위 질문에 대한 답은 아니요입니다.

왜냐하면 저희 프로젝트는 하나의 서버를 사용했습니다. 즉, 세션이나 JWT나 별 차이가 없었을 것입니다.

저는 처음에 "나중에 확장을 할 수 있는데, 그럴 때를 대비해서 사용할 수도 있지 않나?" 라는 생각을 가지면서, 합리화를 했습니다. 틀린 말이 아닐 수도 있죠!

그런데, 저의 팀 프로젝트에서 JWT 인증 방식에 문제가 있었습니다.

바로, access token이 만료됐을 때, refresh token을 통한 재발급 로직을 구현하지 못 했습니다.

주어진 기간 내에 refresh token을 통한 access token 재발급 로직을 개발하기에는 조금 벅찼습니다.
그래서 결국, access token의 시간을 길게 설정하기로 결정을 했습니다.

즉, 굉장히 보안에 취약한 인증 처리를 하게 된 셈이 됐습니다.

이것은 JWT 인증의 문제가 아닌 저희가 개발 계획을 무리하기 짠 문제이기도 합니다.


결론

  • refresh token을 사용하는 로직을 구현하지 못할 거였으면, 그냥 세션 방식을 사용하는 것이 훨씬 잘 만든 애플리케이션이 될 수 있었을 것 같습니다.
  • 만약 access token을 재발급 받는 로직을 완성했다 하더라도, 현 애플리케이션에서 JWT 인증 방식의 장점을 살리지 못하는 이상 세션 방식을 사용하는 것이 더 좋은 선택이었을 거라고 생각합니다!
  • 다음에 이러한 인증 처리를 하게 된다면, 조금 더 신중하게 인증 방식을 선택해야 할 것 같습니다.
profile
집중

0개의 댓글