관리 메뉴

Rootable의 개발일기

JWT vs Session 본문

Network

JWT vs Session

dev-rootable 2024. 1. 26. 21:09

 

📌 세션 동작 방식

 

1. 사용자는 웹 브라우저에 로그인 정보를 입력한 후 웹 브라우저는 서버에 요청을 보낸다.

 

2. 웹 서버는 해당 정보가 올바른 정보인지 검증 후 올바르다면 Session Object and Session ID를 생성하여 Session ID를 쿠키에 담아 클라이언트로 반환한다.

  • 쿠키는 HTTP 전용이므로, 해당 클라이언트의 것이 아닌 어떤 Javascript로도 읽을 수 없다.
  • man in the middle attack과 같은 통신을 가로채는 공격으로부터 안전하다.

 

3. 다음 요청부터 웹 브라우저는 자동으로 해당 쿠키(with Session ID)를 함께 보낸다.

 

4. 서버는 전송받은 Session ID를 검색한 결과(Session Object)가 존재한다면 유효한 요청으로 판단하고 응답을 내린다.

 

출처: https://80000coding.oopy.io/1f213f10-185c-4b4e-8372-119402fecdd0

 

📌 JWT 동작 방식

 

1. 서버는 사용자의 인증 정보를 사용(검증)하여 JWT를 생성한 후 Client로 보냄

 

2. Client는 JWT를 서버에 전송

  • 처음 인증을 받은 후 Client는 JWT 토큰을 저장하게 된다.
  • Client는 다음 요청 때 Authorization 요청 헤더에 토큰을 넣어서 전송한다.

 

3. 서버는 JWT의 Signature를 사용하여 무결성을 확인

 

4. 서버는 JWT의 내용을 사용하여 사용자의 인증 상태를 확인하거나 권한을 부여한다.

 

🤿 Difference Main JWT and Session

 

🔍 How to Store

 

JWT와 Session 방식은 user's authentication information을 어떻게 저장하는지에 차이가 있다.

 

Session은 user's authentication data를 서버 측 Database에 보관한다. 이는 사용자를 위한 primary identifier, 세션 시작 시간, 세션 만료 시간, IP 주소와 같은 추가적인 문맥 정보 등을 포함한다.

 

일단 저장되고 나면, 세션 식별자를 사용자 브라우저에 쿠키로 저장하기 위해 Client로 다시 전송한다.

 

JWT는 서버에 의해 토큰이 발행되자마자 user's authentication data를 JSON 객체로 쿠키 또는 Browser Database(ex. Local Storage or Session Storage)에 저장한다. 해당 JSON 객체는 JWT(토큰)을 의미하며, header와 payload 그리고 이 둘을 조합한 signature(for verification)로 구성되어 있다. 그리고 header와 payload는 사용자 정보를 보호하기 위해 secret key를 통해 해시된다.

 

🔍 Control

 

JWTStateless 특징을 갖고 있다. 즉, 서버는 JWT를 발급하고 나면 이를 더 이상 관리하지 않고 제출받은 JWT를 검증만 한다. 따라서, 설정된 만료 시간이 되기 전까지 JWT를 무효화(ex. 강제 로그아웃)하거나 갱신할 방법이 없다.

 

Stateful 특징을 가진 Session은 각 사용자의 세션 상태를 관리하고, 서버에 있는 세션 저장소의 데이터를 기반으로 검증하므로 중앙 집중화되어 있어 신뢰성이 높다.

 

또한, Session의 Control은 단순하고 명확하다. 이는 세션 저장소에서 특정 세션 레코드를 삭제하거나 유효하지 않은 것으로 표시하는 방식으로 제어할 수 있다.
이렇게 하면 Client의 후속 요청에 대해서 서버는 즉각적으로 401 에러를 응답하여 재인증을 요청한다.

 

이론적으로 JWT를 무효화하기 위해 서명에 사용된 secret key를 폐기하는 방법이 있지만 이는 지속 가능한 방법이 아니다. 이는 해당 key를 사용한 모든 JWT가 무효화되며, 캐시된 유효성 확인 key를 제거하는 작업이 수반되므로 단순한 로그아웃을 위한 적절한 선택지가 될 수 없다.

마찬가지로, JWT에 Role 관련 정보가 포함된 경우 특정 사용자의 Role을 downgrading하여 접근 범위를 축소할 수 있다. 하지만 이것은 JWT가 만료될 때까지는 반영되지 않는다.

 

🔍 Performance

 

JWT 방식에서 사용하는 토큰은 검증을 위해 필요한 정보가 모두 포함되어 있어 서버와 Database에 대한 의존도가 낮다. 이것은 더 빠른 인증을 가능하게 하고, 외부 앱과 더 상호운용적으로 동작하도록 돕는다. 그리고 data 공유에 있어 single domain or sub domain으로 제한하지 않기 때문에 CORS로부터 자유롭다.

 

그렇지만 JWT 방식에서 사용하는 claims는 담긴 정보량에 비례하여 빠르게 커질 수 있다. 대부분 브라우저에서 4KB로 쿠키 크기를 제한하는데 이를 초과하면 400 에러가 발생한다.

 

Session 방식은 더 안전하게 보안을 구축할 수 있지만 병목 현상이 있다.

 

Session은 안정적이고 신뢰할 수 있는 방식을 채택하기 위해 모든 인증마다 Database에 쓰기 요청을 하고, 모든 후속 요청마다 Database에 읽기 요청을 한다. 그리고 세션 만료는 지속적인 사용을 위해 연장되는 경우가 많기 때문에 이러한 요청에 대한 갱신 요청도 포함한다. 이러한 모든 Database와의 상호작용은 application에서 주목할 만한 병목 현상으로 나타난다.

 

🔍 Scalability

 

JWTStateless하기 때문에 확장성이 높다. JWT 방식에서 사용자의 state or session data를 어디에도 저장하지 않기 때문에 거대한 규모의 트래픽 환경에서도 Load Banlancer를 사용하여 쉽게 대규모의 workloads를 처리할 수 있다.

 

반면 Session사용자 수만큼 세션이 생성되기 때문에 사용자 수가 많아지면 서버의 부하를 줄이기 위한 클러스터링 등을 고려해야 한다. 만약 서버를 추가할 경우, 세션을 여러 서버가 나눠 갖게 되고 별도의 중앙 세션 관리 시스템이 필요하므로 확장성이 떨어진다.

 

🔍 Security

 

JWT 방식과 세션 방식에서 보안을 측면에서 각각 취약점을 갖고 있다. JWT의 경우, 클라이언트 측에 저장한다는 점에서 탈취 위험을 생각해야 하고, Session의 경우 session hijacking 등을 통해 이미 인증된 세션을 가로채는 취약점이 있다.

 

Security에 있어서 둘의 차이는 State에서 나온다. 탈취된 이후에 Session 방식은 세션을 통제할 수 있기 때문에 JWT에 비해 능동적으로 대처할 수 있어 신뢰성이 높다.

 

📌 Conclusion

 

크게 JWT는 편리성, Session은 신뢰성에 기반을 두고 있는 것으로 분석된다.

 

JWT 특징 요약

 

  • Stateless 특징으로 서버 부하가 적다.
  • 서버에 의존하지 않기 때문에 확장성이 높다.
  • Stateless 특징으로 세션 통제가 어렵다.
  • claim 정보가 추가되는 만큼 토큰이 커지기 때문에 트래픽이 높아질 가능성이 있다.

 

Session 특징 요약

 

  • Stateful 특징으로 서버 부하가 커질 수 있다.
  • 서버에 의존하기 때문에 확장성이 떨어진다.
  • Stateful 특징으로 세션 통제가 쉬워 신뢰성이 높다.
  • Session 식별자만 전송하기 때문에 적은 트래픽을 사용한다.

 

References:

 

https://devops.com/session-tokens-vs-jwts-choosing-your-session-management-solution/

 

Session Tokens Vs. JWTs: Choosing Your Session Management Solution - DevOps.com

Session tokens and JSON Web Tokens (JWTs) are the two most popular ways to manage user sessions and maintain a user’s authentication state.

devops.com

 

https://www.loginradius.com/blog/engineering/guest-post/jwt-vs-sessions/

 

How to Authenticate Users: JWT vs. Session

In this article, you'll learn the differences between JWT and Sessions, and which one to use for authentication.

www.loginradius.com

 

https://stytch.com/blog/jwts-vs-sessions-which-is-right-for-you/

 

JWTs vs. sessions: which authentication approach is right for you?

Your application just received a login request, and the credentials passed successfully to prove the identity of a user in your system. Wonderful, you have a high degree of confidence in who this user is and what they should be able to access! But wait, wh

stytch.com

 

https://80000coding.oopy.io/1f213f10-185c-4b4e-8372-119402fecdd0

 

로그인 인증방식 어떤게 좋을까? Session VS JWT

로그인 방식을 cookie와 session 방식만 알고 있었는데

80000coding.oopy.io

 

https://velog.io/@gotaek/%EC%84%B8%EC%85%98Session%EA%B3%BC-JWT#-jwt

 

세션(Session)과 JWT

🔎 Authentication vs Authorization 두 개의 단어는 비슷해보이지만 엄연히 다른 프로세스이다. Authentication은 인증이고, Authorization은 권한 부여인데 로그인 시스템에서 중요한 역할을 한다. 웹사이트에

velog.io

 

'Network' 카테고리의 다른 글

HTTP Content-Type  (0) 2024.05.04
OAuth 2.0  (0) 2024.03.31
JWT (JSON Web Token)  (4) 2024.01.25
CORS(Cross-Origin Resource Sharing) Policy  (0) 2024.01.16
HTTP 응답/상태 코드  (0) 2023.07.11