Session and Cookie
Session
- stateless 한 HTTP의 특징을 보완하기 위한녀석
- session DB를 이용하여 유저의 정보를 기억하며 session ID라고 하는 랜덤한 key를 쿠키에 담아 Auth에 활용
- 쿠키를 사용해서 Session ID를 주고 받는것
Cookie
- 웹 브라우저와 요청과 응답을 주고받을때 사용하는 데이터 쪼가리
- cookie는 도메인에 제한적이며 유효기간이 정해져 있음
- Auth 외에도 다양한 방식으로 활용
But
쿠키는 웹 브라우저에만 존재, 이로 인해 다양한 장치들과 공통적으로 사용할 수 있는 방식이 필요
JWT( JSON Web Token )
Token : 랜덤하게 생긴 문자열
문자열.포맷.서명 으로 이루어짐, 여기에는 유저의 간단한 정보가 들어있음
JWT 방식으로 Auth를 처리하면 인증을 위한 여러가지 로직 처리가 필요 없음
처리방식
- 클라이언트가 ID/PW를 서버로 보냅니다.
- 서버에서 ID/PW를 검증하고 유효하다면 일정한 형식으로 서명 처리된 Token을 응답합니다.
- 이후 클라이언트는 모든 요청 헤더에 토큰을 담아 서버로 요청을 전송합니다.
- 서버는 해당 토큰의 유효성을 검증하고 유저의 신원과 권한을 확인 후 요청을 처리합니다.
Session과의 차이
- 세션 데이터베이스가 존재하지 않으며 데이터베이스가 필요하지 않다.
- 토큰 자체가 하나의 인증 데이터
- 서버는 토큰이 유효한지만 검증하여 처리
장점
- 서버에서 관리하는 데이터가 없으므로 복잡한 처리 로직이 필요하지 않습니다.
- 세션이나 DB없이 유저를 인증하는것이 가능합니다
단점
- 일방적으로 로그인을 무효화 하는 등의 처리가 불가능합니다. (세션 테이블 X)
- 모든 기기 로그아웃
- 현재 접속 유저 관리 등
- Token 자체가 데이터를 담고 있는 정보이므로 탈취당할시 보안이 취약합니다.
구조
. 을 기준으로 HEADER, PAYLOAD, VERIFY SIGNATURE 3가지로 구성
HEADER
- 토큰의 타입(jwt) 또는 서명 부분의 생성에 어떤 알고리즘(alg)이 사용되었는지 등을 저장
PAYLOAD
- 토근 발급자, 대상자, 만료시간,활성날짜, 발급시간 등등 표기
- 이부분에 서비스가 유저의 정보를 담아서 인증한다.
- 누구나 볼수가 있기 때문에 최소한의 정보를 저장(해킹방지)
- 각 데이터는 CLAIM 이라고도 하며 KEY - VALUE 으로 구성
SIGNATURE
- HEADER + PAYLOAD + 서버의 비밀키 값을 HEADER에 명시된 암호 알고리즘 방식으로 생성한 값
- 즉 PAYLOAD의 글자 하나만 달라져도 SIGNATURE는 완전히 다른 문자열로 변환되어 서버의 비밀키 값을 모른다면 유효-한 서명값을 만들어내는 것이 불가능
- 서버는 토큰을 받으면 HEADER + PAYLOAD + 비밀키로 생성한 서명값이 토큰의 서명값과 일치하는지를 확인하는 과정을 거쳐서 유효성 여부를 확인
- 서명의 유효여부 + 유효기간 내의 토큰인지 확인하여 Auth 과정을 처리
이제 실행하는 방법(힘들다 적는게)
저거 다 넣고 RUNSERVER 실행 후 POSTMAN ON
