🌙 session 방식?token 방식

인증과 인가

=> 시스템의 자원을 적절하고 유효한 사용자에게 전달하고 공개하는 방법

🌙 인증 (Authentication)

클라이언트가 자기자신이라고 주장하고 있는 사용자가 맞는지 검증하는 과정
너 누군지 인증해봐!
ex) 로그인

 

🌙 인가 (Authorization)

인증 작업 이후에 행해지는 작업, 인증된 사용자의 자원요청에 대한 권한 확인 절차
ex) 내가 작성한 글 수정, 좋아요, 댓글 작성
( 내가 타인이 작성한 글을 수정하거나 제거할 수 없음, 타인의 리소스에 대해서는 인가되어 있지 않기 때문 )

 

🧿 HTTP의 비상태성(Stateless)

HTTP는 비상태성(Stateless)이라는 특성을 가지기 때문에 각  통신의 상태 저장 안됨
( = 서버는 클라이언트의 상태를 저장하지 않음, 바로 직전에 발생한 통신 기억 못함)
하지만 매번 새 페이지를 요청 할 때마다 로그인을 해야한다면 누가 사용할까?
그래서 등장한 것이 바로 세션과 토큰!

 

=> 웹 어플리케이션에서는 이 문제를 세션 또는 토큰을 사용하여 문제를 해결한다

 

🎫 session 기반 인증방식

session기반 인증방식에는 Session과 Cookie가 있음

 

👉유저가 로그인을 함

=> DB에 아이디, 로그인날짜, 유효기간, session id 저장

(이때 세션구분위해 Session id를 기준으로 정보 DB저장)

=> 유저에게는 session id 만 보내줌

=> 클라이언트의 브라우저에 쿠키로 Session Id가 저장됨

=> 쿠키에 정보가 담겨있어  모든 요청들에 대해 Session Id를 쿠키에 담아 전송

=> 서버는 클라이언트가 보낸 Session Id와 서버 메모리를 관리하고 있는 Session Id를 비교해서 일치하면 인가를 수행

 

장점

• 서버의 세션 저장소에 저장하기 때문에 관리가 매우 편하고 효율적
• 발급된 Session ID는 브라우저에 쿠키 형태로 저장되지만, 실제 인증 정보는 서버에 저장되어 있다.
• 유저의 GET/POST요청마다 로그인상태 체크가능

단점 

• 매번 요청시 조회하기 때문에 클라이언트 수가 많으면 DB 부담이 큼 (=> redis:session id보관용 DB 사용 입출력 빠르게함)

세션을 사용하게 될 경우 이러한 단점들로 인해 관리하는 것이 어렵다.

=> 이 문제를 해결한 것이  ‘토큰 방식’임

🎫  JSON Web Token 인방식 (토큰방식 = JWT) 

유저가 로그인을 요청하고 id, pw 정보가 유효하다면 서버에서 Secret Key를 사용해서 유저에게 토큰을 발급
클라이언트는 발급 받은 토큰을 저장하고, 서버에서 요청 할 때 마다, 해당 토큰을 함께 서버에 전달

 

👉유저가 로그인을 함

=> 따로 DB저장 없이 아이디, 로그인 날짜, 유효기간 등 암호화한 후 유저에게 보냄

장점 :  GET/POST요청마다 DB조회 필요없음 ( DB부담 없음), 유저가 많거나 마이크로서비스 운영중이면 편함

단점 : 유저의 JWT를 나쁜 사람이 훔쳐가면 그 사람의 로그인을 막거나 할 수 있는 방법이 없다

그리고 다른 컴퓨터에 저장된 JWT를 소멸시키거나 그럴 수는 없기 때문에 다른 컴퓨터를 로그아웃시키기도 어려울 수 있음

 

가장 큰 차이점!

세션은 데이터베이스 서버에 저장된다는 것,

토큰은 클라이언트 측에서만 저장한다는 것.