-
Notifications
You must be signed in to change notification settings - Fork 0
Jwt 토큰 방식의 로그인
먼저 http는 상태를 저장하지 않습니다. 이를 Stateless하다고 표현하는데 이러한 http의 특성은 서버의 수평적인 확장을 가능하게 하여 서버를 증설할 때 유리하게 작용합니다. 하지만 그렇다고 모든 기능을 Stateless하게 설계할 수는 없는데 예를 들어 로그인한 유저의 정보를 가져오기 위해서 상태유지가 꼭 필요한 로그인 기능이 대표적입니다. 그래서 일반적으로 Jwt토큰을 클라이언트단에 저장해서 사용하는 토큰 방식과 서버의 세션 등을 사용해서 상태를 유지합니다.
서버가 1대인 경우에는 위 그림처럼 서버(세션) 하나에 모든 클라이언트 정보가 저장 되기때문에 문제가 없지만 서비스 규모가 커져서 클라이언트의 정보를 담는 서버의 갯수가 아래의 그림처럼 늘어나면 어떻게 될까요?
예를 들어 클라이언트 1, 2, 3번의 정보가 각각 세션 1, 2, 3에 저장되어 있다고 생각해 봅시다. 이때 클라이언트 1번이 자신의 정보가 저장되어 있는 1번 세션이 아닌 2번이나 3번에 API 요청을 하게 되면 회원 인증 처리에 문제가 생기게 됩니다. 그래서 사용하는 것이 JWT 토큰입니다. JWT 토큰은 서버가 아닌 클라이언트 쪽에 유저 정보를 저장하는데 서버가 가지고 있는 Secret Key를 이용해 로그인에 성공한 클라이언트의 정보를 암호화 한뒤 JWT 토큰 형태로 저장합니다.
- 먼저 JWT 토큰을 사용하면 먼저 서버측의 부하를 낮출 수 있습니다. 각각의 클라이언트 정보를 서버가 아닌 클라이언트 쪽에 저장하고 권한이 필요한 요청을 보낼때 이 JWT 토큰을 포함해서 보내기만 하면 서버가 가지고 있는 Secret Key를 이용해 복호화하여 클라이언트 정보를 사용하면 되니까 훨씬 부담이 덜하겠죠?
-
구현 복잡도 증가합니다.
-
Secret Key 유출 시 JWT 토큰 조작 가능합니다.
-
JWT 토큰이 탈취 당해도 토큰을 만료 시킬수가 없어 악용될 수 있습니다. 이런 경우 만료시간이 비교적 짧은 access token과 만료시간이 긴 refresh token을 같이 발행하여 문제를 해결할 수 있는데 이 방법도 다음 글에서 포스팅 해보겠습니다.