[기술면접] 16일차 문답 | JWT, 쿠키 세션 토큰

💡 JWT에 대해서 설명하시오

 JWT(Json Web Token) 토큰이란 웹에서 사용되는 JSON형식의 토큰에 대한 표준 규격으로, 주로 OAuth나 OIDC 프로토콜과 함께 사용자에 대한 인증이나 인가를(authentication, authorization) 서버와 클라이언트 간에 안전하게 주고 받기 위해 사용한다.

 

 서비스의 인가 서버를 통해 로그인에 성공하면 JWT토큰을 획득하고, 클라이언트는 해당 서비스의 API를 호출할 때 JWT토큰을 보내어 원하는 자원에 접근하거나 허용된 작업을 수행할 수 있게 된다. JWT토큰은 네트워크로 전송되어야하므로 공간을 적게 차지하는 것이 유리하다.

 

 

형태 및 구조

JWT 토큰은 Base64로 인코딩 되어있어 아주 긴 문자열로 이루어져있다. 이 저장된 문자열을 온라인 디버거를 통해 JSON형태로 디코딩하여 확인할 수도 있다.

   JWT 토큰 구조 :

<헤더(header)>,<페이로드(payload)>,<서명(signature)>
헤더(header)에는 토큰의 유형과 서명 알고리즘,

페이로드(payload)에는 claim이라고 불리는 사용자의 인증/인가 정보가 담긴다.

서명(signature)에는 헤더와 페이로드가 시크릿키로 서명되어 저장된다.

 

👍장점

• 확장성이 뛰어나다. JWT는 토큰 자체에 사용자 정보가 저장되어있어 서버 입장에서는 사용자를 인증하기위해 토큰만 검증하면 된다. 쿠키와 세션을 사용할 때는 서버 단에 로그인한 모든 사용자의 세션을 DB나 캐시(cache)에 저장해놓고 쿠키로 넘어온 세션 ID로 사용자 데이터를 매번 조회해야한다. 따라서 JWT는 사용자가 늘어나더라도 사용자 인증을 위한 인프라 비용을 절감할 수 있다.
• 쿠키를 사용하지 않아서 CORS문제에서 자유로워진다

👎 단점

• JWT토큰에 서명된 서버에서만 유효성을 검증하지만 저장된 데이터는 누구나 쉽게 열람이 가능하다 = JWT토큰에 사용자정보를 그대로 저장하는 경우 보안문제가 발생! 따라서 사용자를 식별할 수 있는 아이디 정도만 저장하고 해당 아이디로 DB를 조회하는 것이 안전하며, 민감 정보를 저장할 경우 반드시 암호화를 해야한다. 

 

***쿠키-세션-토큰***

쿠키

• Key-Value 형식의 문자열 덩어리를 브라우저에 저장한 것
• 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일로 사용자마다의 브라우저에 정보를 저장하므로 고유정보 식별이 가능하다

브라우저(클라이언트)가 서버에 요청(접속) -> 서버 응답 (저장 정보를 응답 헤더의 Set-Cookie에 담아 보냄)

이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다. 서버는 쿠키에 담긴 정보를 바탕으로 해당 클라이언트를 식별한다.

👎단점 :

1. 보안에 취약
2. 용량 제한
3. 브라우저 간 공유가 불가능

 

 

세션

• 민감한 인증정보를 서버 측에 모두 저장하고 관리
• Session ID, Value로 구성

클라이언트 요청 -> 서버 (세션 생성 및 유지) -> 응답(브라우저 쿠키에 SessionID를 저장)

이후 클라이언트 요청 시 해당 sessionID가 담긴 쿠키를 서버로 보내게 되며, 서버는 세션 저장소에 있는 sessionID와 클라이언트가 보낸 sessionID를 인증하여 응답을 보낸다.

👎단점 :

1. 유의미한 개인정보는 들어있지 않지만 세션ID를 탈취하여 클라이언트인척 위장이 가능,
2. 요청이 많아지면 서버 부하

토큰

• 클라이언트가 서버에 접속하면 인증되었다는 의미로 토큰을 부여함
• 토큰은 유일하며, 클라이언트 요청 시 헤더에 토큰을 심어 보내고 서버는 받은 토큰과 서버에서 제공한 토큰의 일치여부를 확인하여 인증과정을 처리한다

각 클라이언트가 토큰을 저장하고 있어 서버 메모리나 스토리지에 부담이 줄어든다

앱 - 서버 통신과 인증에서 가장 많이 사용된다. (웹에는 쿠키, 세션이 있으므로)

👎단점

1. 중요한 정보는 담을 수 없다.
2. 토큰을 탈취되면 대응이 어렵다.

 

 

 

 

💡 JWT의 Access Token과 Refresh Token은 왜 필요한가요?

 

Access Token은 접근 관련 토큰, Refresh Token은 재발급에 관여하는 토큰이다.

 

Access Token은 서버에 저장되지 않고 토큰 자체로 검증, 사용자 권한을 인증한다.

Access Token이 탈취되면 토큰이 만료되기 전 까지, 토큰을 획득한 사람은 누구나 권한 접근이 가능해지므로 보안에 취약하다.

JWT는 발급 후 삭제가 불가능하므로 토큰에 유효시간을 부여하는 식으로 탈취 문제에 대해 대응하게 되었는데, 유효시간을 짧게하는 방식은 사용자가 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편하다는 단점이 있다.

따라서 사용자가 처음에 로그인에 성공했을 때 서버는 클라이언트에게 Access Token과 Refresh Token을 동시에 발급한다.

• 서버는 DB에 Refresh Token을 저장하고, 클라이언트는 Access Token과 Refresh Token을 쿠키, 세션 혹은 웹스토리지에 저장하고 요청이 있을때마다 이 둘을 헤더에 담아서 보낸다. Refresh Token은 Access Token보다 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 재발급해주도록 한다.

만약 만료된 Access Token을 서버에 보내면, 서버는 같이 보내진 Refresh Token을 DB에 있는 Token과 비교해 일치하면 다시 Access Token을 재발급해준다. 그리고 사용자가 로그아웃을 하면 저장소에서 Refresh Token을 삭제하여 사용이 불가능하도록 만든다.

 

 

인증 및 재발급 원리 등은 아래 블로그 참고!

https://inpa.tistory.com/entry/WEB-📚-Access-Token-Refresh-Token-원리-feat-JWT

 

 

 

 

💡 JWT Token을 사용할 때의 주의사항은 무엇이 있을까요?

• 토큰 발행자가 JWT의 신뢰에 영향 :
  누가 JWT를 발행했는지 검증하지 못하면 정보의 신뢰성이 떨어짐
  
  
• 토큰에는 민감한 정보를 포함하지 않도록 하기 :
  JWT는 디코딩할 수 있으므로, 헤더와 페이로드는 기밀 정보가 포함되지 않게 주의해야 합니다.
  필요시 JWE(JSON Web Encryption)을 사용해 암호화하여야 한다
  
  
• 토큰의 크기가 너무 크지 않도록 주의 :
  클라이언트에서 토큰을 전송, 토큰 크기가 커지면 성능에 영향을 줄 수 있다.
  이를 방지하려면 필요한 최소한의 정보만 토큰에 포함하는 것이 좋다.

 

 

 

 

💡 Django의 기본 기능을 사용하는 것과 JWT를 사용하여 로그인 기능을 구현하는 것에는 어떤 차이점이 있습니까?

 

 

Django기본 기능과 JWT로의 로그인 구현은 접근 방식과 기능 면에서 차이가 있다.

장고는 세션 기반 인증 방식으로 "django.contrib.auth" 기본적으로 내장되어있는 기능으로 로그인, 로그아웃을 도와준다. 

 

👍 장점

1. 내장기능이므로 구현이 비교적 간단
2. 비밀번호 암호화, 세션 관리 등 보안 기능도 내장
3. 사용자 관리, 권한 기능도 내장

👎 단점

1. 서버 측 세션을 사용하므로 서버에서 세션을 관리해야함 = 확장성 제한
2. 다중 서버 환경에서의 세션 공유 및 관리 문제

 

 

JWT는 토큰 기반 인증 방식으로, 로그인 정보를 JSON 형식의 토큰으로 변환하여 클라이언트에 전달

 

👍 장점 :

1. 서버 측에서 세션 관리가 필요없어 확장성을 가짐
2. 토큰을 클라이언트가 관리하므로, 서버 리소스 부하가 줄어듦
3. 다중 서버환경에서도 토큰을 공유, 사용하는 것이 가능함

👎 단점 :

1. 토큰을 해석하고 검증하는 로직, 보안측면에서 신중한 구현
2. 만료 시간을 관리해야하고 토큰 갱신 로직이 필요함