jwt

 

 

 

문제 상황

1. 

로그인할 때, 사용자가 입력하는 id, password를 db에 기억하고 있다가 같으면 로그인  X

-> db가 해킹 당하면 전부 유출되는 문제가 존재.  

 

2.

페이지를 들어갈 때마다 로그인 상태를 '유지' 시켜주는 문제

 

So, 인증, 인가가 중요

- 인증 : Authentication (로그인)

- 인가 : Authorization (로그인이 유지되는 상태에서 일어나는 것) 

 

Authorization 전통적인 방식 - session

1. 사용자가 로그인에 성공하면 '서버'는 '세션 딱지'같은 걸 출력한다. 
  이 딱지를 찢어서 반쪽은 '사용자의 브라우저'로, 반쪽은 '메모리, db ... ' 등 에 저장함. 

  (메모리에 저장하는게 다른 저장 공간보다는 빠르게 처리해준다.)

2. 브라우저가 이 딱지를 session ID란 이름의 쿠키로 저장 (쿠키 : 브라우저에 저장되는 정보)

    이 브라우저는 다음 사이트에 요청을 보낼때마다 이 딱지를 실어 보냄. 

3. 요청에 session ID라는게 들어오면 -> 서버는 메모리에서 맞는 짝이 있는지를 찾는 것 

 

어떤 사용자가 서버에 로그인 되어있음이 지속되는 상태를 '세션'이라고 함

- 서버가 표 반쪽을 기억해두고 있는 자체

 

허점

- 사용자가 동시에 많이 접속하면 메모리가 부족해질 것
   -> 메모리 특성상 서버에 문제가 있어서 꺼져버리기라도 하면 정보가 날라감 (휘발성)
        사용자는 다시 로그인해야하는 상황이 발생

- 메모리 대신 하드에 저장을 하면? 메모리보다 느리다.

- 서버를 여러대 둔다면? (서버를 분산해서 load balancing)

   만약에 로그인은 1번 서버, 검색 요청하는 서버는 2번 서버에 연결을 하면 2번 서버에는 그 사용자에 대한 정보(딱지)가 없으니 세션 유지가 되지 않음. 

- 복잡한 구성과 환경에서 (사용자가 많아져서 메모리가 부족해진다던지, db에 연결을 하면 무거워진다던지) 어떤 상태를 기억해야한다는 설계가 힘듦 

 

session 방식 해결 -> '토큰 방식'인 jwt 

- json web token

- jwt를 사용하는 서비스에서는 사용자가 로그인을 하면 'token'이라는 표를 (세션때와 마찬가지로) 출력해서 줌

  대신 세션 때와 다른 점은 '찍어서 주지 않고' 그냥 준다. 즉, 서버가 뭔가를 기억하고 있지 않다는 점

- 토큰의 생김새 : feihfisfnjskldoujkalHUgirgeg....

   인코딩/암호화된 3가지 데이터리를 이어붙임 (잘 살펴보면 중간에 마침표가 2개 들어가있다.)
   각각 header, payload, verify signature로 구분됨 

(1) payload 부분 

- (base64로) 디코딩을 해보면 json 형식으로 여러 정보들이 들어있음 

   이 토큰을 누가 누구에게 발급했는지, 언제까지 유효한지, 서비스가 사용자에게 이 토큰을 공개하기 원하는 내용 (사용자 닉네임, 관리자 여부 등) 등의 정보가 있는데 서비스 측에서 원하는대로 담을 수 있음

- 이렇게 토큰에 담긴 사용자 정보 등의 데이터를 claim이라고 함

- 사용자가 이런 정보(claim)을 갖고 있으니, 서버는 요청이 들어올 때마다 일일히 db에서 찾아봐야 할 수고가 줄어들게 됨 

- 허점 : 디코딩해서 볼 수 있기에, 보안에 허점이 존재 (그래서 header, verify signature가 필요) 

(2) header 부분

- 디코딩해서 보면

1) type : 토큰 타입 (여기에는 언제나 jwt가 들어간다. 타입이 jwt여야 jwt인 것이기에 고정값이다.)

2) alg : 알고리즘의 약자.  verify signature을 만드는데 사용될 알고리즘이 지정됨. 

    예를 들어 HS256 등 여러 암호화 방식 중 하나를 지정한다. 

    header, payload, '서버에 감춰놓은 비밀 값' 이렇게 3개를 이 알고리즘에 넣으면 -> verify signature가 나온다.

 

- 서버는 요청에 토큰이 들어오면, header, payload, '서버에 감춰놓은 비밀 값'을 계산해봐서 계산된 결과값이 verify signature 와 같은지를 확인한다. 

- 만약 header, payload 중에 조금이라도 어떤 정보가 수정되었다면 패스가 되지 않음. 

 

✅ 이처럼 시간에 따라 바뀌는 어떤 상태값을 '안' 갖는 걸 'stateless하다'고 함 (반대는 stateful) 

 

그럼 다 jwt 방식으로 쓰면 되는 것인가 

- 세션을 대체하기에는 jwt 방식에는 큰 결점이 존재

   세션처럼 stateful해서 모든 사용자들의 상태를 기억하고 있으면, (구현이 부담스럽지만) 기억하는 대상의 상태를 언제든 제어할 수 있음

   ex) 기기 한 대에서만 로그인 가능한 서비스를 만들었는데, 세션 방식으로 하면 다른 기기에서 로그인을 해왔을 때 pc에서는 로그아웃되도록 컨트롤 가능

<-> 반대로 토큰은 한 번 줘버리 토큰은 회수도 추적도 불가능. 즉, 내가 정보를 가지고 있지 않아서 편하기는하나 통제가 불가능

       더 최악의 상황은 어떤 해커가 토큰을 가져가버리게 되면 그 토큰을 무효화시킬 방법이 없음

- 서버가 아는 것은 오직 토큰이 유효한지 여부. 유저 계정을 잘 관리해야 하는 경우 session을 활용한다. 

   (session처럼 db에 저장하지 않기 때문에 현재 인스타그램에 로그인한 계정이 몇 개인지, 넷플릭스 한 아이디에 몇 명의 유저가 쓰고 있는건지 등을 확인 불가)

- 그래서 생각보다 jwt를 많이 쓰지 않는다.

   jwt를 사용하는 경우는 만료 시간을 가깝게 잡아서 토큰의 수명을 아주 짧게 주는 경우. 

   1) access 토큰 :  수명이 몇 시간이나 몇 분이하로 짧음 

   2) refresh 토큰 : 꽤 길게 (2주 정도) 수명이 있음

- access 토큰과 refresh 토큰을 발급하고 클라이언트에게 보냄

- refresh 토큰은 상용값을 db에도 저장함

- 클라이언트는 access 토큰 수명이 다하면 refresh 토큰을 보냄

- 서버는 그 토큰을 db에 저장된 값과 대조해보고 맞다면 새로운 access 토큰을 발급해줌

- refresh 토큰만 안전하게 관리된다면 이게 유효할동안은 access 토큰이 만료될 때마다 다시 로그인할 필요가 x

 

---

(아래는 기존에 작성했던 내용인데 삭제하려다가, 위에 내용으로 확실히 개념 잡고 다시 읽어봐도 될 것 같아서 남긴다. (흐름이 산재되어 있기에 개념 잡고 읽으면 흐름을 스스로 잡는데 도움이 될 듯ㅎㅎ)) 

 

---

 

 

쿠키

• 서버가 나의 브라우저에 데이터를 넣을 수 있음
  for ‘나'를 기억하기 위해
• 만약 내가 구글에 접속하고 검색어를 입력하면 서버는 내 요청에 대해 response를 주는데 이때 같이 ‘쿠키’도 주는 것. 그리고 내 브라우저는 그 쿠키를 간직해놨다가, 내가 웹사이트에 방문할 때마다 request와 함께 쿠키를 보내게 됨. (들고다니는 열쇠같은 것) 
• 쿠키는 인증에 대한 정보 뿐만 아니라 다른 정보들도 담을 수 있음. ex) 언어 설정 (그래서 내가 다음에 방문할 때는 영어가 아니라 한국어가 뜬다던지)
• 제한 (1) 쿠키는 도메인에 따라 제한됨. 만약 내가 구글 쿠키를 받았으면 구글 웹사이트에서만 유효
• 제한 (2) 유효기간 존재. 서버가 정함

 

stateless 개념

• 서버로 가는 요청들이 이전 request와는 독립적으로 다뤄진다는 것
• 요청이 끝나면 서버는 이 요청이 누구건지 다 잊어버림 -> 요청할 때마다 우리가 누구인지 알려줘야 함
  ✅ 이 방법 중 하나가 바로, session 

 

session

• 세션을 활용해서 안드로이드, ios도 다 만들 수 있지만 이때는 쿠키 사용이 불가. (쿠키는 브라우저에만 있기에)
  ✅ 그래서 token을 사용
• 세션에서 기억해둘 점은, 현재 로그인한 유저들의 모든 세션 id를 db에 저장해야한다는 점
  요청이 올때마다 서버는 쿠키를 받고, 세션 id를 보고, 세션 id와 일치하는 유저를 찾음. 즉 요청이 올때마다 db를 찾아야 함
  ✅ jwt가 등장함 (token 형식)

 

jwt

• 세션 db를 가질 필요 x
  서버는 유저 인증한다고 많은 일을 하지 않아도 됨
• 로그인하려면 서버에 signed info / token을 서버에 보내야 함
  서버는 토큰을 받으면 해당 사인이 유효한지 체크한 후, 유저로 인증
• jwt에서 서버는 유저를 인증하는데 필요한 정보를 '토큰'에 저장. 
  해당 토큰을 브라우저 주고.
  (다음에) 페이지 요청시 서버는 해당 토큰이 유효한지만 검증하면 됨 (db를 거칠 필요가 없음)
  <-> session은 세션에 대한 모든 정보가 세션 db에 있어서 세션 id를 줬어야 했다는 점
• jwt는 암호화되지 않음 (암호화되었다면 아무도 읽을 수 없고, 이해할 수 없음)
  jwt는 누구나 열어서 해당 컨텐츠를 볼 수 있음 (그래서 중요한 내용은 jwt에 두면 안 됨)
• (단점) jwt를 사용하면 생성된 토큰을 추적하지 않음. (session처럼 db에 저장하지 않기 때문에 현재 인스타그램에 로그인한 계정이 몇 개인지, 넷플릭스 한 아이디에 몇 명의 유저가 쓰고 있는건지 등을 확인 불가)
  - 서버가 아는 것은 오직 토큰이 유효한지 여부
  -> 유저 계정을 잘 관리해야 하는 경우 session을 활용

 

 

캐시

• 사용 빈도가 높은 데이터를 고속으로 엑세스 할 수 있는 위치에 두는 것
• ‘바로 사용할 테니까 일단 여기에 두자’
• 단점) 고속으로 엑세스 할 수는 있지만 데이터를 잃을 위험이 있어서 캐시 데이터가 손실돼도 괜찮은 경우에 주로 사용

 

캐시 vs 쿠키

-> 캐시 는 로딩 시간을 줄이기 위해 브라우저 (클라이언트 측)에 웹 페이지 자원을 저장하는 데 사용되는 반면, 쿠키 는 사용자 기본 설정을 추적하기 위해 브라우징 세션을 저장하는 데 사용

 

 

 

 

 

 

출처 : https://youtu.be/tosLBcAX1vk, https://youtu.be/1QiOXWEbqYQ

캐시 vs 쿠키 : https://ko.gadget-info.com/difference-between-cache

캐시 출처 : 책 [it인프라구조]