개발일지

JWT도대체 어디에 저장해야 할까?

졸업작품을 만드는데 로그인을 구현하면서 서버가 넘겨준 jwt토큰을 과연 어디에 저장하고 사용해야 jwt토큰의 장점을 살리면서 보안의 위협도 적어질까라는 고민으로 자료조사를 해보았다

그리 간단한 내용이 아니라는것을 깨닫고 이참에 처음부터 끝까지 정리해보자라는 마음으로 포스트를 업로드했다.

로그인 인증을 할 수 있는 방법인 쿠키/세션,jwt,jwt의 2가지토큰인 Access,refresh token을 업로드하고 보안상으로 문제가 될 수 있는 csrf,xss까지 정리해보았다.(webStorage도)

소셜미디어와 비슷한 성격을 지닌 저의 졸업작품 특성상 한번 로그인하면 로그인한 상태를 쭉 이어가야 했고 그렇다면 그 중 가장 좋은 방법인 refresh token을 과연 어디에 저장하고 사용 해야 가장 안전하면서 로그인한 상태를 유지할 수 있을까 

refresh token을 cookie에 저장하는 경우

(장점)

XSS공격으로 부터 localStorage에 비해 안전하다.

쿠키의 httpOnly 옵션을 사용하여 브라우저에서 쿠키를 접근 할 수 없게 만들어 주고 Secure 옵션을 사용하여 웹브라우저와 웹서버가 HTTPS로 통신하는 경우에만 웹브라우저가 쿠키를 서버로 전송.(httpOnly,Secure는 서버에서 설정)

즉 해커가 사용자의 쿠키를 탈취하기 위해 미리 악성 스크립트 파일을 심어 두어도(xss) 스크립트 파일에 해커가 적어둔 js코드로 쿠키에 접근 자체를 못함(그래도 공격하는 방법이 있다고 함...)

(단점)

CSRF 공격에 취약하다.

쿠키가 자동으로 http request에 담아서 보내기 때문에 공격자가 request url만 안다면 사용자가 관련 link를 클릭하도록 유도하여 request를 위조하기 쉽다.

-> 쿠키에 refresh token이 저장되어잇는 상태에서 서버와 통신을 하면 쿠키 특성상 계속 서버로 보내지기 때문에 해당 링크를 클릭하면 refresh toekn을 이용하여 accesstoken을 탈취해 개인 정보를 빼낼 수 잇음

refresh token을  localStorage에 저장하는경우

(장점)

CSRF 공격에는 안전하다.
자동으로 request에 담기는 쿠키와는 다르게 js 코드에 의해 헤더에 담기므로 공격자가 사용자인 척 request를 보내기 어려움

(단점)

XSS에 취약하다.

자바스크립트 접근이 너무쉬움

그렇다면 도대체 어디?

내가 조사 한 결과 가장 안전하다고 판단 되면서 jwt의 장점을 살릴 수 잇는 방법은 refresh token을 DB에 저장하는 것 이다.

로그인을 하면 서버에서는 access token을 클라이언트에 refresh token의 DB 인덱스값과 함께 보내주고

클라이언트에서는 값을 받아 access token은 클라이언트내에서(유효기간이 짧아 털려도 비교적 괜찮음... 물론털리면 안좋음..) 사용하고 인덱스값은 쿠키나 로컬스토리지에 저장하고 사용한다.

이때 인덱스값을 그냥 넣는것이 아니라 해시화를 진행해주어 보안을 조금 더 유리하게 만들어준다.

결국 refresh token을 클라이언트에서 관리하지 않고 access token만 관리하는 방법을 선택했다.

클라이언트에서 직접 토큰을 관리해 서버 부하를 줄여주자는 jwt의 원래 성격과는 조금 거리가 있으나 보안상 이점도 챙겨면서 세션 방식을 사용한것 보단 서버의 부하를 줄여주는 위의 방법이 그나마 제일 난것같다.

다른 옵션

refresh token을 쿠키에 저장하고 사용하는 방법이다 쿠키에는 Secure,HTTPOnly,Same-Site 등 여러 보안 옵션이 있어 비교적 안전하다고 생각되어 사용하는것 같다.

그럼에도 클라이언트에서 중요한 정보를 다루기에는 여전히 많은 문제가 있고 추후 똑똑한 사람들이 좋은 라이브러리를 만들어 주어 해결 할때 까지 존버하자...

마치며

로그인을 구현하는데 생각보다 복잡한 문제들이 껴 있었고 나는 하나씩 그 문제들을 찾아가며 정리하다 보니 생각보다 오랜시간을 잡아 먹었다.

본인 프로젝트의 특성을 고려하여 UX가 중요한 문제인지 보안이 더 중요한 문제인지를 판단하고 어떤 방법을 사용할 지 결정해야 하는것 같다. 

다음으로는 실제 프로젝트에 직접 적용해보고 포스트를 작성하겠다...

참고자료

https://doogle.link/jwt-%ED%98%B9%EC%9D%80-oauth2-%EC%9D%98-refresh-%ED%86%A0%ED%81%B0%EC%9D%84-%EC%96%B4%EB%94%94%EB%8B%A4-%EC%A0%80%EC%9E%A5%ED%95%B4%EC%95%BC-%ED%95%A0%EA%B9%8C/

https://velog.io/@0307kwon/JWT%EB%8A%94-%EC%96%B4%EB%94%94%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C-localStorage-vs-cookie#1-jwt

Web Storage란?

Web Storage는 2016년부터 실제로 쓰이게 되었으며 브라우저에 매우 종속된 기술이라고 볼 수 있다.

브라우저(클라이언트)에 key-value형태로 데이터를 저장 하는 방식으로 쿠키와 굉장히 유사하다

쿠키와 Web Storage의 차이는 밑에서 보기로 하고 일단 Web Storage에는 Local Storage, Session Storage의 2가지 저장소가 분리되어있다. 

Local Storage

• localStorage는 시간제한이 없고 브라우저가 꺼져도 죽지 않는다. (브라우저를 종료하고 나중에 다시 접속해도 값이 유지가됨)
• 관리자가 데이터를 명시적으로 삭제 시켜줘야만 데이터 삭제가 된다. 
• 탭을 여러개 열어도 공유된다

Session Storage

• 브라우저가 열려있는 동안만 데이터가 살아있으며 브라우저 종료시에 데이터도 함께 없어진다.
• 새로고침을 해도 데이터는 유지된다.
• 탭마다 별도의 저장소가 분리 되어 있어 데이터를 공유하지 않는다

Local Storage , Session Storage의 차이

Local storage와 Session Storage의 가장 큰 차이는 브라우저 종료시 데이터가 사라지냐 이다.

Local Staroage는 관리자가 별도로 데이터를 삭제 해 주지않는 이상 데이터를 계속 가지고 있으며 Session Storage는 브라우저 종료시 데이터가 사라지는 것을 볼 수있다!

Cookie와 WebStorage의 차이

1.제한

cookie - 용량제한, 시간제한, 갯수제한 존재

webstorage - 용량제한만 존재

2.시간제한 설정

cookie - 시간제한 설정가능

webstorage - 시간제한 설정 불가능

3.데이터형

cookie - 문자열만 저장가능

webstorage - javascript 객체 저장가능

4.데이터 전송

cookie - 모든 쿠키를 전송해야함, cookie를 가공함으로써 발생하는 side effect존재

webstorage - 개발자가 선택해서 전송할 수 있고 가공할 수도 있음

5.세션의 정의

cookie - 같은 브라우저면 다른 탭이나 다른 창(프로세스)일지라도 같은 세션이라고 정의

webstorage - 같은 브라우저일지라도 sessionStorage의 경우 다른 탭이면 다른 세션이라고 정의

6.이벤트

cookie - 이벤트 없음

webstroage - 이벤트 존재

쿠키와 비교해서 WebStroage가 더 나은 모습을 보이지만 데이터의 영속성 때문에 유지보수,데이터관리를 함에 있어 조금 더 까다로운점이 존재한다.

마지막으로 글을 조금 더 보태자면 세션은 이러한 클라이언트에서 데이터를 보관하는 방법보다 더 안전한 방법이다.

하지만 서버에 걸리는 부하때문에 cookie와 webstorage같은 곳으로 데이터를 분산한다.

참고 자료

https://velog.io/@ejchaid/localstorage-sessionstorage-cookie%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

https://kamang-it.tistory.com/entry/Web%EC%A1%B0%EA%B8%88-%EB%8D%94-%EC%9E%90%EC%84%B8%ED%9E%88cookie%EB%8A%94-%EB%84%88%EB%AC%B4-%EA%B5%AC%EC%8B%9D%EC%95%84%EB%83%90-%EC%9D%B4%EC%A0%9C%EB%B6%80%ED%84%B4-Web-Storage

Refresh Token이란?

Refresh Token은 Access Token과 마찬가지로 로그인을 할때 서버에서 발급해주는 jwt(json web token)이다

그렇다면 왜 로그인을 했을때 서버에서 2가지의 토큰을 발급 해 주는 것일까?

이 문제의 해답은 Access Token의 단점과 연결 된다.  

2021.08.02 - [Web] - JWT 지난 포스트에서 jwt의 단점 중 Access token을 발급하고 유효기간이 지나기 전 까지는 해커에게 토큰이 털려도 손 쓸 방법이 없다고 글을 작성했다. 그렇다면 "Access token의 유효기간을 짧게 하면서 문제를 해결 할 수 있는 방법이 없을까?"

라는 물음의 답이 바로 Refresh token인 것이다.

예를 들어 Refresh Token의 유효기간은 1주, Access Token의 유효기간은 1시간이라 생각해보자. 

사용자는 1시간동안 Access token을 이용하여 서버로부터 데이터를 받을 수 있으며 1시간이 지나면 다시 로그인을 하는 방식이 아닌 그 전에 발급 받은 refresh token으로 다시 Access token을 발급 받는 것 이다.

이런 refresh token의 장점은 Access token으로만 데이터를 주고 받는 서버에서 Access token의 유효기간을 줄이고 보다 더 안전한 사용이 가능하게 만들어 준다.

하지만 refresh token 또한 단점이 존재한다

일단 구현자체가 좀 복잡하고 refresh token을 어디에 저장해야 안전한지 (다음 포스트예약) 만약 refresh token을 탈취 당한다면 어떻게 해야할지 등 여러 문제가 있다.  

그럼에도 현재 로그인을 구현하는 가장 대표적이고 안전한 방식이 refresh token을 사용하는 것이라는 거에는 변함이 없다.

Refresh Token인증과정

1번부터 7번까지의 과정은 Access Token의 인증과정과 별 다를게 없다(refresh token을 함께 받아오는것 빼곤)

만약 Access Token의 유효기간이 만료가 되면 서버는 클라이언트에서 보낸 Access token의 유효기간이 지난 것을 확인하고 유효기간이 지났다고 응답한다. 그 다음 Access token의 재발급을 위해 클라이언트는 refresh token을 보내며 서버는 이를 확인 하고 Access token을 발급한다 

9~11의 과정은 프론트쪽에서 Access Token의 Payload를 통해 유효기간을 알 수 있어 유효기간이 끝나가는 시점에서 자동으로 Access Token을 재발급 받아주는 로직을 작성하면 된다.

참고

https://tansfil.tistory.com/59?category=475681 

JWT란?

Json Web Token의 약자로 모바일이나 웹의 사용자 인증을 위해 사용하며 인증에 필요한 정보들을 암호화시킨 토큰을 뜻한다!(토큰기반 인증방식)

https://jwt.io jwt사이트를 들어가 보게되면 암호화된 토큰을 볼 수 있는데 

토큰을 만들기 위해서는 크게 3가지, Header,Payload, Verify Signature가 필요하다!

Header : 위 3가지 정보를 암호화할 방식(alg 알고리즘 Verify Signature를 만드는 알고리즘이 들어감), 타입(jwt고정) 등이 들어감

Payload : 서버에서 보낼 데이터가 들어가며 일반적으로 유저의 고유 ID값, 유효기간이 들어간다

Verify Signature :  Base64 방식으로 인코딩한 Header,payload 그리고 SECRET KEY를 더한 후 서명된다.

최종적인 결과 : Encoded Header + "." + Encoded Payload + "." + Verify Signature

Header, Payload는 인코딩될 뿐(16진수로 변경), 따로 암호화 되지않는다. 따라서 누구나 디코딩하여 정보를 볼 수 있으며 Payload에 유저의 비밀번호같은 중요한 데이터가 들어 가면 매우 위험하다!

하지만 Verify Signature는 SECRET KEY를 알지 못하면 복호화할 수 없다!

예를 들어 사용자 A가 사용자 B의 정보를 훔쳐보고 싶어 Payload에 있던 A의 id대신 B의 id로 다시 인코딩한 후 받아온 토큰 값을 서버로 보냈다고 가정해보자.이때 서버에서는 Verify Signature 검사를 하게 되는데 Payload에 B의 id가 들어 있어도 A의 Payload로 기반으로 만들어진 Verify Signature때문에 유효하지 않은 토큰인 것 을 알 수 있다!결국 SECRET KEY를 알지 못하면 토큰을 조작 할수 없다는 것을 알 수 있다

JWT 인증방식

사용자가 로그인을 하면 서버에서는 DB에서 사용자가 맞는 지 확인 한 후 Access Token을 발급 하여 사용자에게 보내준다.

이렇게 로그인이 되고 사용자는 데이터를 요청하기위해 발급 받은 Access Token을 다시 서버로 보낸다. 그러면 서버는 Access Token값을 기준으로 판단하여 사용자가 맞는지 판다하고 요청하는 데이터를 응답해준다.

(장점)

1. 세션/쿠키는 별도의 저장소의 관리가 필요한것에 비해 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없어 간편하다.

이는 Stateless 한 서버를 만드는 입장에서는 큰 강점이다!

Stateless : 어떠한 별도의 저장소도 사용하지 않는, 즉 상태를 저장하지 않는 것을 의미한다

2. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하여 확장성이 뛰어남. (ex FaceBook,Google)

(단점)

1. 이미 발급된 JWT에 대해서는 돌이킬 수 없다. 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버리면 된다. 하지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하여 한번 털리면 유효기간 끝날때까지 방법이 없다.

-->  해결책 : 기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급한다(다음 포스트 당첨)

2. Payload 정보가 제한적이다. 위에 말했던 이유인 Payload의 값은 누구나 디코딩이 가능하여 중요한 정보를 넣을 수 없다!

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

참고 

https://tansfil.tistory.com/58?category=475681 

CSRF란?

사이트 간 요청 위조또는 크로스 사이트 요청 위조(Cross-site request forgery, CSRF, XSRF)는  웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말한다.

CSRF공격을 성공하려면 

• 사용자가 로그인이 되어 있어야한다.
• 사용자가 해커가 심어놓은 게시글이나 이미지를 클릭해야한다!

밑에 글을 보며 자세히 이해해보자!

CSRF의 공격순서

1. 먼저 해커가 보안이 취약한 웹사이트에 HTTP로 작성된 요청문을 게시글에 작성한다(사용자의 정보를 얻기위해 해당 게시글을 누르면 작성된 요청문이 실행되어 해커에게 정보가 날라감)
2. xss와 마찬가지로 해커에게 정보가 날라가는 요청문이 DB에 저장되게 된다.
3. 사용자가 게시판을 내려보다 해커가 심어놓은 해당 게시글을 클릭하게되면 해당 링크 또는 해당 게시글의 이미지를 클릭햇을때 해커가 작성한 HTTP요청을 사용자 본인의 권한으로 실행하게 된다 (이때 사용자가 로그인이 되어있어야함, 로그인이 되있는 상태에서 클릭시 해커가 심어놓은 HTTP요청을 사용자 본인의 요청으로 실행하게되고 해당 정보는 해커에게 넘어간다)

CSRF의 취약한지 판단하는 방법

위의 사진처럼 img src를 이용하여 유저를 강제 로그아웃(사용자에게 피해를 끼치는) 시키는 코드를 작성하고 임의의 유저가 해당 이미지를 클릭시 해당 요청이 실행된다면 csrf의 취약하다고 판단할 수 있다 (img는 기본적으로 get요청을 사용하기 때문에 위와 같은 코드가 가능함)

실제로 2008년 옥션에서 발생했던 관리자 계정 탈취 사건도 관리자가 admin 권한으로 로그인 한 상태에서 피싱 메일을 열람하였고 피싱 메일안에 숨겨진 CSRF코드가 실행되어 관리자 권한을 탈취하게 된 것이다.

그렇다면 CSRF의 대응 할 수 있는 방법!

1. Referrer 검증법

클라이언트가 서버로 데이터를 요청할때마다 request의 header에 담겨있는 referrer값을 확인하여 같은 도메인에서 보낸 요청인지를 확인하고 차단하는 방법이다.

하지만 동일 사이트 내에서 XSS 취약점이 발견된다면 이를 통하여 CSRF 공격을 실행할 수 있다는 점을 유의해야 하며 이는 페이지 단위까지 쪼개어서 도메인 검증을 하는것으로 페이지 간 CSRF 공격을 방어할 수 있다!

2. CSRF Token 사용

사용자의 세션에 임의의 값을 저장하여 모든 요청마다 그 값을 포함하여 전송한다.(세션로그인 방식)

그리고 요청이 들어올 때 마다 백엔드에서 세션에 저장된 값과 요청으로 전송된 값이 일치하는지 검증하여 방어하는 방법!

referrer 검증법과 같이 XSS를 통한 CSRF 공격에 취약하다는 특징이 있다!

XSS와 CSRF의 차이

- XSS는 사이트변조나 백도어를 통해 클라이언트에 대한 악성공격을 한다.

- CSRF는 요청을 위조하여 사용자의 권한을 이용해 서버에 대한 악성공격을 한다.

참고사이트

https://tibetsandfox.tistory.com/11

https://crossjin.tistory.com/entry/CSRFCross-Site-Request-Forgery%EB%9E%80

XSS란?

Cross site scripting의 약자로 원래 css라고 부르는 것이 맞지만 우리가 아는 Cascading style sheets(Css)때문에 Xss로 불리게 되었다.

xss는 웹메일이나 게시판등에 자바스크립트와 같은 스크립트 파일을 해커가 삽입하여 다른 유저에게 피해를 끼치는 것을 뜻한다.

예를 들어 우리가 만든 게시판이 있을때 한사용자 A가 게시판에서 글을 작성하여 서버는 이를 받아 DB에 저장하였다고 치자.

그러고 다른 사용자 B가 A의 글을 읽었을때 해커가 미리 심어둔 xss공격으로 게시판 글에 다른 스크립트 파일이 들어가 있어 사용자 B는 해커가 심어둔 스크립트 파일이 실행 되게된다.

발생 할 수 있는 피해

1. 쿠키 정보 및 세션 ID획득
   해커가 만약 스크립트 파일에 해커 본인의 url로 쿠기값을 보내는 코드를 삽입했으면 쿠기값이 해커에게 날라가고 그 안에 만약 세션Id값이 들어가 있을 경우 세션 Id마저 털리게 된다 😱
2. 악성 코드 다운로드
   xss자체로는 프로그램을 다운 할 수 없지만, 만약 해커가 프로그램을 다운 할 수 있는 url을 스크립트 파일로 걸어 놓았다면...?
3. 거짓 페이지 노출
   사이트와 전혀 상관없는 페이지를 노출 시킬 수 있다.

해결방법

◆ 입력 값 치환
XSS 공격은 기본적으로 <script> 태그를 사용하기 때문에 XSS 공격을 차단하기 위해 태그 문자(<, >) 등 위험한 문자 입력 시 문자 참조(HTML entity)로 필터링하고, 서버에서 브라우저로 전송 시 문자를 인코딩하는 것이다. HTML 문자 참조란 ASCII 문자를 동일한 의미의 HTML 문자로 변경하는 과정이다. 예를 들어, 문자 “<”는 동일한 의미의 HTML “&lt;” 로 변경한다. HTML 엔터티는 대부분의 인터프리터(특히, 브라우저)에서 특수한 의미를 가지지 않으며, 단순한 문자로 처리된다. 이렇게 인코딩하면 사용자는 <script>가 <script>로 보이지만 HTML 문서에서는 &lt;script&gt; 로 나타나서 브라우저에서 일반 문자로 인식하고 스크립트로 해석되어 실행되지는 않는다.

스크립트란? : 스크립트는 보통 인간 운영자에 의해 행하여질 수 있는 일련의 작업의 자동화이다

-->  요약 : 정규식을 이용한 파라미터 값 필터링 (방어력 Level 1~10에서 3정도..?)

◆ 보안 라이브러리 사용

역시 젤 편한 방법으로는 만들어진 라이브러리를 갖다가 사용하는것이다👍(그것도 대기업에서 만들어진 보안 라이브러리를...!)

대표적인 것으로는 OWASP Antisamy이나 NAVER Lucy XSS Filter, ESAPI 등이 있다!!

참고자료 

http://blog.plura.io/?p=7614 

https://www.youtube.com/watch?v=LfI6TAchgT4&list=PLDV-cCQnUlIbH2r12z_ZE2xAChDw3nASv&index=10 

쿠키와 세션을 사용하는 이유

(cookie는 클라이언트에 정보를 저장하는 기술, session은 서버에 정보를 저장하는 기술이다.)

• http 프로토콜의 취약점을 해결해 주기위해서 사용한다 
• HTTP 프로토콜 환경에서 서버는 클라이언트가 누구인지 확인해야한다 그 이유는 HTTP 프로토콜이 connectionless, stateless한 특성이 있기 때문이다. 
  
  • connectionless(비연결 지향) : 클라이언트가 서버로 부터 데이터를 요청한 후 데이터가 성공적으로 응답이 되면 연결을 바로 끊어 버리는 형식 
  • stateless(상태없음) : 통신이 끝나면 상태를 유지하지 않는 특성(상태 정보를 유지시키지 않음

http프로토콜의 이런 취약점을 해결 하기위해  쿠키와 세션을 사용하는 것이다!

1. 사용자 정보를 기억하기 위해
2. 클라이언트에서 서버로 인증하기 위한 절차 반복을 줄이기 위해

그렇다면 쿠키와 세션이란 무엇일까?

쿠키 

• 쿠키는 클라이언트 로컬(local)에 저장되는 키와 값(key, value)이 들어있는 작은 데이터 파일이다.
• 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다.
• 만료 날짜/시간을 지정하지 않으면, '메모리에 있는 동안' 계속 유효하다고 판단하도록 세션 쿠키에 저장되고, 만료 날짜/시간을 지정하면 프로세스가 종료되더라도 특정 만료날짜/시간까지 유효하므로 지속 쿠키에 저장된다.지속 쿠키는 파일로 저장되므로 브라우저가 종료되어도 쿠키는 남아있게 된다.
• 세션 쿠키는 브라우저 메모리에 저장되므로 브라우저가 종료되면 쿠키는 사라지게 된다.

쿠키의 구성요소

• 이름(name) : 각각의 쿠키를 구별하는 데 사용되는 이름
• 값(values) : 쿠키의 이름과 관련된 값
• 유효시간(expires) : 쿠키의 유지시간
• 도메인(domain) : 쿠키를 전송할 도메인
• 경로 (path): 쿠키를 전송할 요청 경로

쿠키의 동작 방식

• 클라이언트가 페이지를 요청
• 서버에서 쿠키를 생성
• HTTP 헤더에 쿠키를 포함 시켜 응답
• 브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있음
• 같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄
• 서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트 하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답

쿠키 사용예시

• 방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"
• 쇼핑몰의 장바구니 기능
• 팝업에서 "오늘 더 이상 이 창을 보지 않음" 체크

세션

• 세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다(클라이언트에게 세션 ID발급해서 클라이언트는 쿠키로 저장 이 때문에 쿠키를 기반한 방식이라함)
• 사용자의 대한 정보를 서버에 두기 때문에 쿠키 방식보다 보안에 더 장점이 있으나 사용자가 늘어날수록 서버 메모리의 큰 부담을 줘 성능 저하를 일으킬 수 있다.
  (추가 8.3) 사용자의 대한 정보를 메모리 > 하드디스크 > db(빨리 가져올 수 있는 순서)에 골라서 저장할 수 있다 
  메모리에 저장하는 경우 휘발성인 메모리의 특성상 서버가 꺼지면 사용자의 정보가 전부 사라진다
  그래서 레디스같은 메모리형 데이터베이스에 저장시키는데 이마저도 서버 에러가 발생하면 데이터가 전부 날라가는 문제점이있다!

• 위의 이유로 서버를 여러대 두고 사용 세션방식을 이용 할 수 있으나 이 방법 또한 문제가 있다. 서버가 예를 들어 A,B,C가 있을시에 클라이언트가 처음 세션ID를 A라는 서버에서 발급받고 B라는 서버에 요청을 보내게 되면 B서버에서는 A서버에서 발급해준 세션ID를 알 지 못함으로 적절한 응답을 해줄 수 없다.

세션 동작 방식

• 클라이언트가 서버에 접속 시 세션 ID를 발급 받는다.
• 클라이언트는 세션 ID에 대해 쿠키를 사용해서 저장하고 가지고 있다.
• 클라리언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 서버에 전달해서 사용함
• 서버는 세션 ID를 전달 받아서 별다른 작업없이 세션 ID로 세션에 있는 클라언트 정보를 가져온다.
• 클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답함

쿠키와 세션의  차이점

• 저장 위치
  • 쿠키는 클라이언트(브라우저)에 메모리 또는 파일에 저장하고, 세션은 서버 메모리에 저장된다.
• 보안
  • 쿠키는 클라이언트 로컬(local)에 저장되기도 하고 특히 파일로 저장되는 경우 탈취, 변조될 위험이 있고, Request/Response에서 스나이핑 당할 위험이 있어 보안이 비교적 취약하다. 반대로 Session은 클라이언트 정보 자체는 서버에 저장되어 있으므로 비교적 안전하다.
• 라이프 사이클
  • 쿠키는 앞서 설명한 지속 쿠키의 경우에 브라우저를 종료하더라도 저장되어 있을 수 있는 반면에 세션은 서버에서 만료시간/날짜를 정해서 지워버릴 수 있기도 하고 세션 쿠키에 세션 아이디를 정한 경우, 브라우저 종료시 세션아이디가 날아갈 수 있다.
• 속도
  • 쿠키에 정보가 있기 때문에 쿠키에 정보가 있기 때문에 서버에 요청시 헤더를 바로 참조하면 되므로 속도에서 유리하지만, 세션은 제공받은 세션아이디(Key)를 이용해서 서버에서 다시 데이터를 참조해야하므로 속도가 비교적 느릴 수 있다.

세션/쿠키 인증 방식

(장점)

세션/쿠키 방식은 기본적으로 쿠키를 매개로 인증을 거치며 여기서 쿠키는 세션 저장소에 담긴 유저 정보를 얻기 위한 열쇠라고 생각하면 된다. 따라서 쿠키가 담긴 http요청이 도중에 노출이 되더라도 쿠키 자체(세션ID)는 유의미한 값을 가지고 있지 않아 보안이 쿠키만을 사용한 방식보단 훨씬 좋다. 또한 사용자 A,B가 있을때 고유의 ID값을 각각 받아 서버에서 사용자의 요청이 들어와도 일일이 회원 정보를 확인 하지 않고 어떤 회원인지를 바로 확인 할 수 있어 서버 자원에 접근이 용이하다.

추가 : 해커에게 세션 id를 털리거나 id변질시 해당 세션을 삭제 할 수 있음!!!!

(단점)

장점에서 쿠키를 탈취당하더라도 안전 할수 있다고 했지만 해커가 쿠키를 훔쳐 http요청을 보내면 서버의 세션 저장소에서는 사용자라고 판단하여 정보를 뿌려주게 된다.(세션 하이재킹 공격이라고 부름)

또한 앞서 정리한 성능 문제 및 서버를 여러대로 분산시킬 시에 발생하는 문제 등이있다.

이러한 쿠키/세션 방식을 해결하기 위한 방법으로 jwt가 등장했다..

(사실 여기까지의 글은 jwt글을 쓰기위한 빌드업 이였다....)

참고사이트 

출저 : https://tansfil.tistory.com/58?category=475681 

https://interconnection.tistory.com/74

https://jeong-pro.tistory.com/80