?

JWT에 대해서 배웠고 Session방식의 보완이라고 들었는데 정확히 Cookie/Session이랑 JWT 인증방식 정확히 어떤 차이점이 있고 장/단점이 있는지 분석

쿠키/세션 방식

1) 인증 방식 순서

1. 사용자가 로그인을 한다.

2. 서버에서는 계정정보를 읽어 사용자를 확인한 후, 사용자의 고유한 ID값을 부여하여 세션 저장소에 저장한 후, 이와 연결되는 세션ID를 발행합니다.

3 사용자는 서버에서 해당 세션ID를 받아 쿠키에 저장을 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보냅니다.

4. 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대응되는 정보를 가져옵니다.

5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내줍니다.

세션 쿠키 방식의 인증은 기본적으로 세션 저장소를 필요로 한다. 세션 저장소는 로그인을 했을 때 사용자의 정보를 저장하고 열쇠가 되는 세션 ID값을 만든다. 그리고 HTTP 헤더에 실어 사용자에게 돌려보낸다. 그러면 사용자는 쿠키로 보관하고 있다가 인증이 필요한 요청에 쿠키(세션ID)를 넣어 보낸다.

• 세션ID를 쿠키라고 봐도 동일, 쿠키가 사용자 개념에서 더 큰 범주. 세션ID를 쿠키로 저장.

2) 장점

1. 세션/쿠키 방식은 기본적으로 쿠키를 매개로 인증을 거칩니다. 여기서 쿠키는 세션 저장소에 담긴 유저 정보를 얻기 위한 열쇠라고 보시면 됩니다. 따라서 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체(세션 ID)는 유의미한 값을 갖고있지 않습니다(중요 정보는 서버 세션에) 이는 위의 계정정보를 담아 인증을 거치는 것보단 안전해 보입니다.

• 쿠키에 담긴 HTTP 요청이 도중에 노출이 되더라도 쿠키 자체(세션 ID)는 유의미한 값을 갖고 있지 않기 때문에 안전합니다.
• 일일이 회원정보를 확인할 필요가 없이 바로 어떤 회원인지를 확인할 수 있어서 서버의 자원에 접근하기 용이합니다.

3) 단점

• ****쿠키 탈취 자체는 안전하지만, 만약에 HTTP 요청을 해커가 가로챈다면 그 안에 있는 쿠키를 가로채서 HTTP 요청을 보낼 수 있습니다. (세션 하이재킹 공격) => HTTPS 사용, 세션에 유효기간을 넣어주기.
• 서버에서 세션 저장소를 사용한다고 하기에 추가적인 저장공간을 필요로 하게되고 자연스럽게 부하도 높아질 것이다.

JWT 방식

인증에 필요한 정보들을 암호화시킨 토큰을 말한다. Access Token을 HTTP 헤더에 실어 서버로 보내게 된다.

JWT 구성요소

1. Header : 위 3가지 정보를 암호화할 방식(alg), 타입(type) 등이 들어갑니다. (agl:HS256, type:jwt)

2. payload : 서버에 보내질 데이터. 유저 아이디, 유효기간  등이 들어갑니다.

3. Verify Signature : Base64로 인코딩한 Header와 Payload, SECRET KEY

장점

1. 간편합니다. 세션/쿠키는 별도의 저장소의 관리가 필요합니다. 그러나 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없습니다. 이는 Stateless 한 서버를 만드는 입장에서는 큰 강점입니다. 여기서 Stateless는 어떠한 별도의 저장소도 사용하지 않는, 즉 상태를 저장하지 않는 것을 의미합니다. 이는 서버를 확장하거나 유지,보수하는데 유리합니다.

2. 확장성이 뛰어납니다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능합니다. 예를 들어 Facebook 로그인, Google 로그인 등은 모두 토큰을 기반으로 인증을 합니다. 이에 선택적으로 이름이나 이메일 등을 받을 수 있는 권한도 받을 수 있습니다.

1. Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있습니다.
2. 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태가 됩니다.
3. 확장성이 우수합니다.
4. 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능합니다.
5. OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있습니다.
6. 모바일 어플리케이션 환경에서도 잘 동작합니다.
7. JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됬음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있습니다.

단점

1. 이미 발급된 JWT에 대해서는 돌이킬 수 없습니다. 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버리면 됩니다. 하지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능합니다. 따라서 악의적인 사용자는 유효기간이 지나기 전까지 정보 탈취가 가능합니다.

• 1번 해결책 기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급합니다. 그렇게 되면 Access Token을 탈취당해도 상대적으로 피해를 줄일 수 있습니다.
  

2. Payload 정보가 제한적입니다. 위에서 언급했다시피 Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있습니다. (세션/쿠키 방식에서는 유저의 정보가 전부 서버의 저장소에 안전하게 보관됩니다) 따라서 유저의 중요한 정보들은 Payload에 넣을 수 없습니다.

3. JWT의 길이입니다. 세션/쿠키 방식에 비해 JWT의 길이는 깁니다. 따라서 인증이 필요한 요청이 많아질 수록 서버의 자원낭비가 발생하게 됩니다.

4. 토큰을 탈취당하면 대처하기 어렵습니다.

5. 특정 사용자의 접속을 강제로 만료하기 어렵지만, 쿠키/세션 기반 인증은 서버 쪽에서 쉽게 세션을 삭제할 수 있습니다.

JWT 방식과 쿠키/세션 방식의 차이

세션/쿠키 방식과 가장 큰 차이점은 세션/쿠키는 세션 저장소에 유저의 정보를 넣는 반면, JWT는 토큰 안에 유저의 정보들이 넣는다는 점입니다. 물론 클라이언트 입장에서는 HTTP 헤더에 세션ID나 토큰을 실어서 보내준다는 점에서는 동일하나, 서버 측에서는 인증을 위해 암호화를 하냐, 별도의 저장소를 이용하냐는 차이가 발생합니다.

Session Problem 1 - 서버 확장시 세션 정보의 동기화 문제

서버가 스케일아웃 돼서 여러 개가 생기면 각 서버마다 세션 정보가 저장된다.로그인시(서버1), 새로고침(서버2) 로 접근하면 서버는 인증이 안됐다고 판단한다.

Session Problem 2 - 서버 / 세션 저장소의 부하

세션을 각 서버에 저장하지 않고 세션 전용 서버, DB에 저장해도 문제가 생긴다.모든 요청 시 해당 서버에 조회해야 한다. DB 부하를 야기할 수 있다.

Session Problem 3 - 웹 / 앱 간의 상이한 쿠키-세션 처리 로직

기존의 Client는 웹 브라우저가 유일했다. 그러나 이제는 모바일로 접근하는 경우도 처리해야 한다.웹 / 앱 의 쿠키 처리 방법이 다르고 또 다른 Client 가 생겨나면 쿠키-세션에 맞게 처리해야 한다.

Token - Self-contained & Stateless

앞의 문제를 해결하는 최선의 방법은 토큰이다.토큰은 서버의 상태를 저장하지 않는다. 토큰 자체로 정보를 가지고 있기 때문에 별도의 인증서버가 필요없다. 따라서 요청을 받을 서버 자체에서 인증 프로세스를 수행할 수 있다.또한, JSON 포맷으로 통신하기 때문에 어떤 Client 에서든 Data 통신에 JSON을 이용하면 토큰을 이용할 수 있다.