프로젝트에 JWT를 도입하게 된 과정

이 포스트에선 프로젝트에 JWT 인증 방식을 채택하기 까지의 과정, 그리고 도입하면서 생긴 문제들을 해결한 방법에 대해서 써보려고 합니다.

 

우선 JWT를 이야기 하기전에, 인증과 인가에 대한 개념을 짚고 넘어가야 합니다.

인증 (Authentication)

인증은 특정 방법을 통해서 사용자의 신원을 검증하는 것을 말합니다.

여기서 말하는 특정 방법이란,

• 비밀번호
• 인증 앱
• 얼굴 인식

이와 같은 여러 방법들이 존재합니다. 인터넷 뿐만 아니라, 실생활에서도 대입할 수 있는데 편의점에서 주류를 구매하기 위해서 신분증으로 인증하는 것도 사용자의 신원을 검증하는 과정이라고 볼 수 있습니다.

 

인가 (Authorization)

인가란, 사용자에게 특정 리소스나 기능에 엑세스 할 수 있는 권한을 부여하는 프로세스를 의미합니다. 앞서 이야기 했던 신분증으로 사용자의 신원을 증명하고 나면, 주류를 구매할 수 있습니다. 만약에 사용자의 신원을 검증하는데 실패한다면, 당연하게도 구매할 수 없습니다.

 

웹사이트에선, 사용자가 로그인 상태여야지만 수행할 수 있는 동작을 말합니다.

 

이처럼 인가는 인증의 결과에 따라 사용자에게 권한을 부여하고, 또 제한 할 수 있습니다.

 

웹사이트에서는 보통 사용자의 아이디, 혹은 이메일과 비밀번호를 통해서 인증 과정을 진행합니다. 인증 과정을 통과하고 나서야, 비로소 로그인이 됩니다.

 

그런데, 프로젝트에선 인가를 어떻게 표현할 수 있을까요?

 

사용자가 로그인 상태일때는 글을 작성할 수 있는 권한이 있고 비로그인 상태일 때는 권한이 없는 상황을 어떻게 구현할 수 있을까요? 쉽게 이야기 해서, 어떻게 서버가 로그인 상태라는 것을 판단할 수 있을까요?

---

세션 

사용자가 로그인에 성공하면, 서버는 SessionID를 발급해주고, 이를 클라이언트에 전달해줍니다. 클라이언트는 이 SessionID를 통해서 서버에게 인가 요청을 하고, SessionID 값에 따라 인가 처리를 해줍니다.

세션 동작 방식

 

그림에서 보다싶이, 서버가 인증 정보를 관리하게되며 stateful 합니다. stateful은 또 무엇을 뜻할까요?

Stateful (상태 유지)

장점

• 서버에서 인증 정보를 관리하므로, 사용자에 대한 접근 제한, 권한 설정 등을 서버가 원하는 시점에서 관리할 수 있습니다.

단점 

• 항상 같은 서버가 유지되어야 해서, 확장성이 낮습니다.
• 서버가 유저 정보를 관리하고 있어서, 트래픽이 많은 경우엔 많은 메모리와 리소스를 사용할 수 있습니다.

Stateless (무상태)

장점

• 응답 서버를 쉽게 바꿀 수 있어서 서버를 많이 증설 가능합니다. 
• 클라이언트에서 많은 요청이 들어와도 서버를 증설하여 유연하게 대처할 수 있습니다. (Scale-out)

단점

• 서버가 유저 정보를 관리하지 않고, 클라이언트가 유저 정보를 관리하기 때문에 관리가 힘들고, 탈취에 대해서 취약합니다.

Stateful과 Stateful을 판단하는 기준은, 서버가 인증 정보를 관리하는지 여부에 따라서 결정됩니다.

 

세션 동작 방식은 서버에서 인증 정보를 관리하기 때문에 Stateful 하다고 볼 수 있고, 하지만 그로 인해서 서버 부하가 많이 가해질 수 있다는 단점이 있습니다.

 

쿠키

클라이언트가 서버에 로그인 요청을 하면, 서버는 쿠키에 인증 정보를 담아서 클라이언트에 보내고, 앞으로 인가 요청을 할 때마다 클라이언트는 서버에 쿠키를 담아서 보내고, 서버는 쿠키 정보에 따라서 인가 처리를 해줍니다.

쿠키 동작 방식

 

쿠키는 클라이언트에서 인증 정보를 관리하기 때문에 Stateless 합니다. 이 때문에 서버 부하가 적다는 장점이 있지만 심각한 보안 문제가 있습니다.

 

• 클라이언트가 강제로 쿠키에 담긴 인증 정보를 위조할 수 있습니다.
  • 쿠키에 담긴 id=2 라는 값을 다른 사람이 알고 있다면, 이를 통해서 로그인을 할 수 있습니다.
• 쿠키가 한번 탈취당하면, 해커가 탈취된 쿠키를 계속 사용할 수 있습니다.

인증 정보를 위조할 수 있다는 단점 때문에, 쿠키 인증 방식을 로그인에서 잘 채택하지 않는 이유이기도 합니다.

 

JWT 토큰 

JWT 토큰 방식도 서버가 아닌 클라이언트가 인증 정보를 관리하기 때문에 쿠키와 동작 방식이 유사합니다.

토큰 동작 방식

 

클라이언트에서 인증 정보를 관리하기 때문에 stateless 하고, 서버 부하가 적습니다.

 

JWT 토큰 방식이 쿠키보다 더 선호되는 이유는, 토큰 검증을 추가로 하기 때문에 쿠키에 비해 보안상에 이점이 있다고 볼 수 있습니다. 

 

 

결론적으로, 쿠키는 보안문제가 있기 때문에 제외하고, 세션을 사용할 것인가 JWT 토큰을 사용할 것인가 두가지 중에서 고민을 했는데 최대한 stateless한 특성을 살리고, 또 확장성을 고려하여 JWT 토큰을 사용하기로 했습니다.

 

하지만 요구 사항에 따라서 세션을 사용하는 경우도 있으니, 이 부분은 추후에 알아보려고 합니다.

 

JWT에 관한 내용과 실제 코드에 도입하게 된 내용은 다음 포스트에서 설명하겠습니다.

 

Reference

https://www.okta.com/kr/identity-101/authentication-vs-authorization/

인증과 인가 (권한 부여) 비교 – 특징 및 차이점 | Okta Identity Korea

 

https://80000coding.oopy.io/9a56cae9-8626-4025-b3f9-c02251980d0f

토큰과 세션, Stateful과 Stateless

https://ksh-coding.tistory.com/113

[인증/인가] 쿠키 VS 세션 VS 토큰 (JWT) 방식 중 무엇을 사용할까?