일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- chrome extension typescript boiler plate
- 로또 몰래카메라
- cloudfront
- extension
- 리액트네이티브
- 프로젝트
- 2024년 개발자회고
- 나락퀴즈
- react-three-fiber
- 리액트
- 프론트 개발자
- 구글 이미지 다운
- ReactNative
- 토이프로젝트
- three.js
- React
- 사이드 프로젝트
- 어플
- Chrome Extension
- react-mocking
- 개발자
- 2024년회고
- Google Image Crawler Chrome Extension
- 프론트엔드
- 네이버 로또
- 디지몬상테스트
- 로또 몰카
- react mociking
- Google Image Crawler
- 똥피하기
- Today
- Total
개발 블로그
로그인 - 세션 vs JWT 본문
https://www.youtube.com/watch?v=1QiOXWEbqYQ
해당 영상을 보고 정리해보았다.
인증( Authentication ):
로그인이다. 특정 서비스에 일정 권한이 주어진 사용자임을 아이디와 패스워드를 통해서 인증을 받는 것이다.
인가( Authorization ):
로그인 이후 서비스의 여러 기능을 사용할 때 서버측에서 로그인 유무를 확인하여 허가해주는 것. 로그인이 유지된 상태에서 일어나는 일.
어떤 사이트나 서비스에 사용자가 로그인 했다는 사실을 알 수 있는 방법은 뭐가 있을까?
일차원적으로 생각해보면, 매 요청마다 아이디와 비밀번호를 같이 보내서 인증을 하면되지 않을까?
- 당연히 안된다. 우선 로그인(인증) 작업은 꽤 무거운 작업이다.
로그인은 DB에 저장된 사용자의 정보를 가져와서 요청에 같이 날아온 아이디와 비밀번호 를 비교해야한다. 이 때 비밀번호는 암호화를 하여서 서로 비교를 하게 된다. 암호화와 데이터베이스에서 매번 꺼내어오는 작업을 거쳐야하기 때문에 비용이 많이 든다.
또한 매 요청마다 아이디, 비밀번호가 같이 날아오면 보안상 위험할 수가 있다.
1. 세션방식
로그인 성공 -> 세션 표딱지(Session ID)발급 -> 반으로 짜겜 -> 반은 메모리(서버)에, 반은 쿠키(브라우저)에 줌 -> 브라우저는 매요청시마다 쿠키에 세션표딱지(Session ID)를 넣어서 요청을 보냄 -> 인가가 가능해짐.
문제점?
- 메모리에 Session ID 를 저장하다 보니 로그인중인 유저가 많아지면 부하가 많이 발생한다.
- 에러가 발생하거나 해서 서버가 꺼지면 메모리는 휘발성이다 보니 사용자들의 로그인이 바로 풀리게 된다.
Session: 어떤 사용자가 서버에 로그인이 지속되는 상태를 세션이라고 함.
2. JWT (JsonWebToken) 방식
로그인 성공 -> 토큰 발급 -> 브라우저에 줌 -> 매요청마다 쿠키에 토큰을 넣어서 요청을 보냄. -> 헤더, 페이로드, 서버의 비밀키값 세가지를 암호화하여서 VERIFY SIGNATURE 값과 비교함. -> 같으면 인가.
---
토큰을 조작할수 있지 않냐?
- 토큰은 조작이 불가하다. 이유는 토큰의 형태를 보면 알 수 있다.
---
토큰의 형태는 HEADER.PAYLOAD.VERIFY SIGNATURE 이렇게 구성됨.
HEADER:
{
type: jwt, // 고정값
alg: VERIFY SIGNATURE에서 지정될 알고리즘이 뭔지 ( 암호화 알고리즘 ex- HS256 )
}
PAYLOAD:
{
데이터
}
VERIFY SIGNATURE: 헤더와 페이로드 서버에 감춰놓은 비밀값 이 세가지를 암호화(alg에 명시되어 있는 알고리즘으로)한 값
VERIFY SIGNATURE 값은 서버에 저장되어 있는 값과 헤더 페이로드 세가지 값을 모두 암호화 한 값이 되기 때문에
만약 누군가 PAYLOAD 의 데이터를 조작해버리면 기존에 VERIFY SIGNATURE 값과 암호화한 값이 완전히 다른 값이 되어버리기 때문에 서버측에서 인가를 해주지 않는다. 그러므로 토큰의 조작은 불가능하다.
JWT방식의 문제점?
- 세션방식은 서버에 Session ID 값을 저장하고 있기 때문에 통제가 가능한데 JWT 방식은 통제를 못한다.
( 예를 들어 한 서비스에 피씨로 로그인을 하고 있고 동시에 휴대폰으로 로그인을 한다고 할때 세션 방식은 피씨 로그인을 끊어버릴 수가 있는데 JWT방식은 그렇지 못하다. )
---
그래서 많은 곳에선 access Token 과 refresh Token 방식을 쓴다. ( 아래 방식은 수많은 방식 중 하나 )
1. 로그인 성공 -> access Token, refresh Token 두개를 발급 -> 브라우저에게 줌. 이 때 refresh token은 상응값을 데이터베이스에 저장함. -> access Token을 요청마다 보내고 만약 유효기간이 지났다면 refresh Token을 보냄 -> DB에 저장된 refresh Token 과 비교해보고 같다면 access Token 을 재발급함.
'웹' 카테고리의 다른 글
동기, 비동기, 블로킹, 논블로킹 가장 명확하고 쉽게 정리해보자 (2) | 2023.11.28 |
---|---|
git 프로젝트 세팅 방법 및 실무에서 사용하는 명령어 정리, vscode 확장프로그램 추천 (2) | 2023.11.26 |
HTTP 메시지 ( 미완) (0) | 2022.08.25 |
URL과 리소스 (0) | 2022.08.18 |
OSI 7계층, TCP/IP 계층, TCP/IP Updated 계층 (0) | 2022.08.06 |