로그인 [ 쿠키,세션 vs JWT ]

Cookie

---

쿠키란 클라이언트가 어떠한 웹사이트를 방문할 경우 , 그 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일을 일컫는다.

 

서버는 클라이언트의 로그인 요청에 대한 응답을 처리 할 때 , 클라이언트 측에 저장하고 싶은 정보를
응답 헤더의 'Set-Cookie'에 담아서 보낸다.

쿠키는 Key-Value 형식의 문자열이다.

클라이언트는 요청을 보낼 떄 마다 , 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다.

 

단점

---

• 보안에 취약하다
  • 요청 시 쿠키의 값을 그대로 전송
  • 유출 및 조작 당할 위험이 존재한다.
• 쿠키에는 용량 제한이 있어 많은 정보를 담을 수 없다.
• 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 공유가 불가능하다.
• 쿠키의 사이즈가 커질수록 네트워크에 부하가 심하다.

 

 

cookie&Session

---

비밀번호 등 인증 정보를 쿠키에 담아 전송하게되면 유출 및 조작 위험이 존재하였다.
때문에 , Session은 인증 정보를 서버 측에 저장하고 관리한다.

 

서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 때 , 인증 정보는 서버에 저장하고 클라이언트 식별자 세션ID를 쿠키에 담는다.

클라이언트는 요청을 보낼 때 마다 세션ID를 쿠키에 함께 보낸다.

서버는 세션ID 유효성을 판별하여 클라이언트를 식별한다.

 

장단점

---

• 쿠키를 포함한 요청이 외부에 노출되더라도 세션 ID 자체는 유의미한 정보를 담지 않는다.
  그러나, 해커가 이를 중간에 탈취하여 클라이언트인척 위장 할 수 있다.
• 각 사용자마다 고유한 세션ID가 발급되기 때문에 회원정보를 확인할 필요가 없다.
• 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다.

 

JWT

---

JWT ( Json Web Token ) 은 인증에 필요한 정보들을 암호화 시킨 토큰을 의미한다.
JWT 토큰을 HTTP 헤더에 실어서 서버가 클라이언트를 식별한다.

 

구조

---

• Header
  

  {
      "alg" : "HS256",
      "typ" : "JWT"
  }​

  
  alg와 typ는 각각 정보를 암호화할 해싱 알고리즘 및 토큰의 타입을 지정한다.

 

• Payload
  

  {
      "sub" : "1234567890",
      "name" : "John Doe",
      "iat" : 1516239022
  }​

   

  payload는 토큰에 담을 정보를 지니고 있다.

 

• Signature
  

  HMACSHA256{
      base64UrlEncode(header) + "." + 
      base64UrlEncode(payload),
      your-256-bit-secret
  }​

  
  Signature는 인코딩된 Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성한다.
  따라서, Signature는 토큰의 위변조 여부를 확인하는데 사용된다.

 

 

인증과정

---

1. 클라이언트 로그인 요청
2. 서버는 검증 후 클라이언트 고유 ID 정보를 payload에 담는다.
3. 암호화할 비밀키를 사용해 Access Token( JWT ) 을 발급
4. 클라이언트는 전달받은 토큰을 저장도의 저장
5. 서버에 요청할 때 마다 토큰을 요청 헤더에 포함시켜 전달
6. 서버는 토큰의 Signature를 비밀키로 복호화 한 다음, 위변조 여부 및 유효 기간을 확인한다.
7. 유효한 토큰이라면 요청에 응답

 

 

 

장점

---

• Header와 Payload를 가지고 Signature를 생성하므오 데이터 위변조를 막을 수 있다.
• 인증 정보에 대한 별도의 저장소가 필요 없다.
• JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됐음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
• 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태가 된다.
• 확장성이 우수하다.
• 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.

 

 

단점

---

• JWT는 토큰의 길이가 길어 네트워크 부하가 심해진다.
• Payload자체는 암호화되지 않기 때문에 중요한 정보는 담을 수 없다.
• 토큰은 한 번 발급되면 유효기간이 만료될 때 까지 계속 사용이 가능하기 때문에 탈취당하면 대처하기 어렵다.

 

 

보안전략

---

1. 짧은 만료 기한 설정
   토큰의 만료 시간을 짧게 설정하는 방법.
   토큰이 탈취되더라도 빠르게 만료되기 때문에 피해를 최소화 할 수 있다.
2. Sliding Session
   글을 작성하는 도중 토큰이 만료가 된다면 작업이 정상적으로 처리되지 않는다.
   서비스를 지속적으로 이용하는 클라이언트에게 자동으로 토큰 만료 기한을 늘려주는 방법
3. Refresh Token
   클라이언트가 로그인 요청을 보내면 서버는 Access Token 및 그 보다 긴 만료 기간을 가진 Refresg Token을 발급하는 전략
   클라이언트는 Access Token이 만료되면 Refresh Token을 사용하여 재발급 요청을 한다.
   서버는 DB에 저장된 Refresh Token과 비교하여 Access Token을 발급하거나 로그인을 요구한다.