ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [Web] 세션, 토큰, 쿠키, JWT 기본 개념 (feat. 노마드)
    CS/Web 2022. 12. 11. 18:19

    참고: https://devjem.tistory.com/13 JWT와 세션 기반 인증 방식의 차이점

    참고(payload에 어떤 유저 정보가 담기나 설명해줌) : wally.velog

    참고:  https://www.youtube.com/@nomadcoders

     

    쿠키

    • 쿠키를 이용해서, 서버는 유저의 브라우저에 데이터를 넣을 수 있다. ( 유저에 대한것을 기억하기 위해)
      • 사이트에 방문하면 브라우저는 서버에 요청을 보낸다
      • 서버는 이에 응답
      • 응답에는 요청한 모든 데이터와 유저가 찾던 페이지 정보가 들어있음.
      • 또한 그 안에는 브라우저에 저장하고자 하는 정보가 담긴 쿠키가 있을수 있음
      • 브라우저는 쿠키를 받게 되면 일단 저장을 한 후 이후에 요청이 있을때마다 쿠키도 요청과 함께 보낸다
      • 쿠키는 도메인에 따라 제한이 됨(유튜브가 준 쿠키는 유튜브에만 한정, 기간도 유효)
      • 인증 & 여러가지 정보 가짐 ( 언어설정 등등 ) 

    세션

    노마드 코더 유튜브

    • 세션과 토큰이 필요한 이유는 HTTP 프로토콜에 대한 이해가 필요하다.
      • HTTP 프로토콜Stateless 특징을 가져서 서버로 가는 모든 요청이 이전 요청과 독립적으로 다뤄진다.
      • 요청끼리 연결x 메모리x, 요청 끝나면 서버는 우리가 누군지 잊음
      • 그래서 요청할 때마다 유저는 자신을 서버에게 알려줘야 하기 때문에 사용되는 것이 세션이다.
    • 유저가 로그인 하기 위해 아이디 비번을 입력후 서버에 보낸다
      • 로그인 정보가 맞다면, 서버는 세션 DB에 유저를 생성한다.
      • 해당 세션에는 별도의 id가 있다.
      • 해당 세션 id는 쿠키를 통해 브러우저로 돌아오고 저장
    • 따라서 같은 웹사이트의 다른 페이지로 이동하면, 브라우저는 세션id를 갖고있는 쿠키를 서버에 보낸다
      • 서버는 들어오는 쿠키를 보고, 세션id와 함께 오는 쿠키를 확인
      • 서버는 우리가 누구인지 모름
      • 세션id가 있는 쿠키를 지닌 요청이 있다는 것만 알뿐
    • 해당 세션 id를 가지고 세션 db를 확인
      • 거기서 해당 id는 유저명에 대해 알고 서버는 그제서야 우리가 누군지 안다.
      • 해당 요청이 끝나고 다른 페이지로 이동하게 되면 이 모든 프로세스가 반복
    • 유저가 갖고 있는 것은 세션 id뿐
      • 쿠키는 그저 세션id를 전달하기 위한 매개체일뿐 
      • 사용자에 대한 중요한 정보가 쿠키에 있다면 보안상 큰 문제가 됨
      • 하지만 그러한 정보는 모두 서버에 있고 브라우저의 쿠키에는 세션 ID만 있기에 보안성 유지됨.

    토큰

    •  안드로이드, ios로 세션을 만들수는 있지만 쿠키를 만들순 없어서 토큰이 생김
    •  토큰은 그냥 이상하게 생긴 스트링

    JWT (JSON Web Token) 

    • JWT는 인증을 위한 토큰 기반 시스템이다 ( 이상하게 생긴 string 형식 eg. QR 코드 체크인
    • JWT는 세션의 단점을 보완한다.
      • JWT로 유저 인증 처리하면, 세션 db를 가질 필요 없고 서버는 유저 인증한다고 많은 일 x
      • 세션은 현재 로그인한 유저들의 모든 세션id를 db에 저장해야한다.
      • 요청이 들어올때마다 서버는 쿠키를 받아서, 세션 id를 보고, 일치하는 유저를 찾아야 하고 그제서야 다음 작업을 수행
      • 요청이 있을때마다 db를 찾아야 하고 유저가 늘어남에 따라 db리소스가 증가함
    • JWT 의 동작 원리 && 세션과의 차이
      • 유저가 로그인을 시도하면 유저명과 비번이 서버에 전달됨.
      • jwt는 디비에 따로 저장 x, 대신 서버는 유저의 id를 가져다가 사인 알고리즘을 이용해서 사인을 한다.
      • 해당 사인된 정보는 string 형태이고, 그것을 유저에게 보낸다 (보통의 세션 ID 보다 훨씬 김)
      • 쿠키는 공간 제약 있지만  JWT는 공간 제약 덜 함.
      • 이 후 유저가 서버에 요청할 때 사인된 정보(토큰)을 서버에 보냄 - JWT(Token)
      • 서버는 그것을 받으면 해당 사인이 유효한지(+조작 여부) 체크한다.
      • 유효한다면 서버는 유저로 인정해줌

    세션 , JWT 비교

    • 세션
      • 세션에선 그냥 세션id만 두면 됨(세션에 대한 모든 정보는 세션db에 저장되어있음)
      • 페이지를 요청하면 서버는 세션id를 디비에서 찾으면 되는것
      • 세션을 사용하면 서버는 로그인 된 유저의 모든 정보를 저장
      • 해당 정보를 이용하면 새로운 기능을 추가 가능 (특정 유저 아웃 가능 - 세션 삭제를 통해. 유저의 모든 정보 갖고 이으니까 ) 
      • 서버가 로그인 유효성을 조정 가능한 것은 세션 db가 있어서 가능
      • 단점은 db 구매 및 유지 비용 
    • JWT
      • JWT는 서버에서 유저를 인증하는데 필요한 정보를 토큰에 저장
      • 페이지를 요청하면 서버는 해당 토큰이 유효한지만 검증(db거칠 필요 없음)
      • 암호화 되지 않음.  (누구나 열어서 해당 컨텐츠 볼 수 있음) - 비밀 정보는 JWT에 담지 말기(Iron-session으로 보완 가능) 
      • 생선된 토큰 추적x ( 서버는 토큰의 유효성만 체크 가능)
      • db구매 x, 빠르고 가볍
      • 강제 로그아웃 못시킴 (해당 토큰 만료전까지는 유효해서) 

    한줄 요약

    • 쿠키: 무언가를 옮기는 매개체
    • 세션: 사용자의 모든 정보를 가진 시스템
    • 토큰: 서버가 기억하는 이상하게 생긴 스트링
    • JWT: 사용자 정보를 갖고 있는 토큰

     

Designed by Tistory.