HTTP #9 세션-쿠키, JWT토큰

로그인/로그아웃처럼 상태정보를 유지하기위해 쿠키를 사용한다.

쿠키에 사용자 정보를 넣는다면 중간에 가로채서(intercept) 정보가 탈취/유출될 수 있다.

쿠키를 암호화한다 한들, 암호화된 쿠키를 한번 탈취당하면 평생 재사용 가능하다.

 

그래서 웹 서버에 'Session 저장소'를 따로 만들어 사용하는게 일반적이다.

그리고 그 이후에 나온 방식인 JWT 토큰에 대해서도 알아보자.

 

참고로 데이터 관점에서 보는 물리적인 의미는 다음과 같다.

• Cookie : 브라우저에서 응답요청에 포함하여 보내는 데이터
• Storage : 브라우저에서 사용하는 데이터. 쿠키처럼 자동으로 응답에 포함하지 않는다.
• Session : 서버가 가지고 있는 저장소, 유효기간이 없는 Session Cookie를 함께 활용
• Token : 인증을 위해 사용되는 암호화된 문자열. JSON 같은 형식의 데이터를 Base64로 암호화한 것이다.
  ➡ 클라이언트에서는 브라우저 LocalStorage에 토큰값 저장하고, Static 변수로 불러와서 사용한다.

 

# Session과 Cookie

서버의 세션서장소를 이용하고 사용자에겐 세션Key(JSessionID)를 쿠키로 전달하는 방법이다.

HttpSession 객체를 이용해서 이미 만들어진 세션저장소를 쉽게 사용할 수있다.

 

그러면 아래와 같은 인증절차를 밟아 로그인하게 된다.

1. 사용자가 로그인을 하면 HTTP POST로 [ID, PW 정보]를 서버에 전달한다.
2. 서버에서는 사용자를 인증한다.
   ➡ 인증에 성공한다면 사용자데이터를 HttpSession에 저장하고 세션ID를 발행한다.
3. 인증에 성공했다면 서버는 세션ID(JSessionID)를 응답에 넣어 보낸다.
4. 이후 클라이언트는 세션쿠키에 있는 JSessionID를 요청에 함께 보내서 로그인되었음을 증명한다.
5. 서버에서는 사용자 요청에 JSessionID가 있다면 세션저장소에서 필요한 데이터를 꺼내고, 요청을 허락해준다.
   ➡ 모든 Controller에 세션검증을 넣으면 번거롭다. 스프링 인터셉터를 이용해 세션을 관리하자.

@ Session의 장단점

• 장점 : 서버에서 상태를 관리할 수 있다. 또한 클라이언트의 정보노출을 막을 수 있다.
• 단점1 : JSessionID를 탈취해버리는 세션 하이재킹을 당할 수 있다.
• 단점2: 세션은 계속해서 쌓인다. 이는 서버의 저장소를 계속 차지하고, 서버에서 세션을 관리하는 부하가 생긴다.
  ➡ 세션값을 유지해야 하기에 HTTP의 무상태성, 비연결성에 얻는 서버 Scale-Out의 장점을 잃는다.

 

---

# HTTP Authentication 제어 헤더 - Basic

HTTP는 다른 인증 프로토콜을 사용할 수 있도록 WWW-Authenticate 와 Authoization 제어 헤더를 제공한다.

• 클라이언트는 Authorization 헤더에 인코딩 문자열(* 암호화 된 것이 아님)을 전송한다.
  ➡ [ username+":"+password ] 값을 Base64로 인코딩하여 [ Basic YWxhZGRpbjP... ] 으로 서버로 보낸다.
• 서버는 해당 값을 디코딩하여 읽어들이고, 401 Unauthorized 발생 시 WWW-Authenticate에 실패이유를 응답한다.

출처 : MDN Web Docs

 

 

# HTTP Authentication 제어 헤더 - Bearer

Bearer는 짐꾼, 운반인을 의미한다. JWT와 같은 토큰 인증 방식에서 사용된다.

• 로그인 시 [로그인하는 서버 or 다른 인증서버]로 부터 Token(암호화된 문자열)을 응답 받는다.
• 이후 요청시 Authentication 헤더에 Token 값을 넣어 보낸다.
• 세션 정보가 토큰 자체에 내장되어 있다. ➡ 무상태 HTTP 요청을 유지할 수 있다. (서버 성능과 보안이 뛰어나다)

 

---

# Token - JWT (Json Web Token)

JWT는 인증에 필요한 정보들을 인코딩 시킨 한 문자열을 의미한다.

서버에 응답 받을 때에는 Body에 받고, 이후 Authorization 헤더에[ Bearer <token value> ]로 넣어 보낸다.

Token에는 서버의 비밀키로 만든 전자서명이 포함되어 있다. 그 외의 데이터는 암호화 되어있지 않다.

만들어진 토큰(암호화된 문자열)은 HTTP 헤더의 Authorization에 적어서 보낸다.

Encoded Header + "." + Encoded Payload + "." + Verify Signature

• Token : 인증을 위해 사용되는 암호화된 문자열. JSON 같은 형식의 데이터를 Base64로 인코딩한 것이다.
  ➡ 클라이언트에서는 브라우저 LocalStorage에 토큰값 저장하고, Static 변수로 불러와서 사용한다.

 

• Header에는 누구나 읽을 수 있는 암호화 방식(alg), 데이터 유형타입(typ)등을 포함한다.
• Payload는 누구나 읽을 수 있는 서버에 보낼 데이터이다. (사용자의 ID정보, 유효기간등이 포함되어있다)
• Verify Signature는 [Base64로 인코딩한 Heaer+Payload] 와 비밀키로 만든 암호화된 전자서명이다.
  
  

Payload안에 있는 각각의 데이터들을 클레임(Claim)이라고 부른다. "sub": "12345" 이런 것들

 

 

• 토큰 Payload에 들어있는 데이터(Claim)들은 아래와 같다.

 

 

 

세션과 다른점은, JWT는 서버에서 세션저장소를 따로 관리하지 않는다.

• 각각의 요청을 별개로 처리한다.
• Header와 Verify Signature는 누구나 읽을 수 있지만 Payload는 암호화된다.
  ➡ 이 Payload안에 사용자 로그인에 필요한 정보(이름,ID)같은게 다 포함되어있다.
• 다만 세션에 비해 전송하는 글자수가 훨씬 길어 네트워크 비용이 증가한다는 단점이 있다.

 

 

인증절차는 아래와 같다.

1. 사용자가 로그인을 한다.
2. 서버에서는 JWT의 계정정보를 읽고 사용자의 고유 ID값을 부여해 Payload에 넣는다.
   ➡ JWT 토큰의 유효기간을 설정하고 Payload를 암호화하여 Access Token을 응답에 넣어보낸다.
   ➡ 그리고 읽을 수 있는 Header와 전자서명 Verify Signature를 Access Token에 넣어준다.
   
3. 사용자는 Access Token을 저장한 후, 인증이 필요한 요청을 할 때마다 토큰을 같이 보낸다.
4. 서버에서는 토큰의 Verify Signature를 비밀키로 복호화하여 조작여부, 유효기간을 확인한다.
5. 서명검증이 완료되었다면 Payload를 디코딩하여 토큰에서 사용자 정보를 읽어들인다.

토큰에서 암호화된 데이터를 꺼내쓴다.

 

 

@ 토큰(JWT)의 장단점

• 세션/쿠키와 다르게 별도의 저장소가 필요없고, 서버에서 비밀키 하나만 가지고 있음되기에 간편하다.
  ➡ 여러 서버에서 세션저장소를 동기화하는 귀찮은 작업이 필요없다. Scale-Out이 쉬워진다.
• 발급한 토큰을 다른 인증시스템과 연동해서 사용가능하다. (=토큰 기능의 확장이 쉽다.)
  ➡ 예를 들어 Facebook, Google에서 발급한 토큰을 이용해서 내 사이트에 로그인하는 OAuth2등을 만들 수 있다.

단점은 아래와 같다.

• 결국 요청에 실어서 보내야하기에 많은 데이터를 포함하기 힘들고, 네트워크 비용의 낭비가 생긴다.
• Payload는 누구나 읽을 수 있으므로 민감한 데이터를 넣어서는 안된다.
• JWT에 유효기간이 만료되기 전까지 계속 사용가능하다. 토큰 자체를 훔치면 답이없다.
  ➡ 그래서 Access Token의 유효기간을 짧게하고, Refresh Token이라는 새로운 토큰을 발급하는 방법을 사용한다.
  ➡ Refresh Token은 AccessToken을 받기위한 토큰이다. 이렇게 구성하면 서버에서 탈취를 감지했을 때 Refresh Token 요청을 거부하여 특정 세션을 멈추게 할 수 있다.
• 보통 유효기간을 1시간/30일 이렇게 사용하며 그냥 AccessToken만 사용하는 사이트도 있긴하다. (github등)

 

# 세션/쿠키 vs 토큰(JWT)

세션/쿠키 방식은 매번 SessionId를 이용하여 세션 저장소에서 찾아야하는 번거로움이 있다.

또한 서버에서 공통된 세션 상태를 관리해야한다. 여러 서버에서의 세션 동기화 문제가 있다.

 

 

 

2021.12 추가내용