일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- binaray_gap
- Linux
- 캐나다워홀
- 벤쿠버집구하기
- FK 설정
- 부산입국
- 엔테크서비스
- QA엔지니어
- 백준알고리즘
- 설탕문제
- IntelliJ
- BC렌트
- 데이터의 무결성
- 레노보노트북
- 리눅스
- Lesson2
- codility
- 자바
- database연결
- 1463번
- 벤쿠버렌트
- 벤쿠버 렌트
- 파이도 환불
- 외래키설정
- Lesson3
- 언마운트
- 프로그래머스
- Java
- FLEX5
- FIDO 환불
- Today
- Total
대충이라도 하자
Session과 JWT 본문
Session
웹사이트에서 로그인을 한다고 생각해보자.
- 이메일이랑 패스워드를 입력하고 브라우저는 서버에 요청을 보낸다.
- 서버는 패스워드 해시랑 동일한지 비교하고, 동일하면, 특정 세션 ID를 만든다. + session storage에 저장
- 서버는 쿠키에 세션 ID를 담아 되돌려 보냄(HTTP only)
=> 내 것이 아닌 자바스크립트로 읽을 수 없음
=> insecure한 connection으로 이전 불가능, encrypted되지 않음
=> man in the middle attck이 가능
- 이 다음부터는 브라우저가 요청을 보낼 때마다, 쿠키에 세션 ID를 담고 서버는 session storage에서 정보 확인
JWT
마찬가지로, 브라우저가 요청을 보내고 서버는 패스워드 해쉬 매칭 확인
- 매칭이 맞으면, JSON signature token을 만든다. ( token은 secret으로 signed)
- 쿠키에 web signature token를 담아 return
Problem
은행 고객 정보가 유출되었고, 은행에 전화해서 계정을 lock해 달라고 한 상황을 가정
은행에서 JWT 인증 방법을 사용한다면, 문제가 발생 -> JWT는 stateless이기 때문
state를 찾아 가능한다고 해도 그렇게 하게 되면 JWT Token을 사용하는 목적을 잃어버리는 것이 된다.
(for stateless 유지)
그리고 그 고객을 포함한 모두를 log out 시켜야 할 가능성이 있음
Session의 경우, 한 고객만을 찾아서 로그아웃시키는 것은 문제도 아니다. 왜냐하면 고객의 state가 저장되기 때문
데이터 가시성
server-side 세션을 사용하게 되면, app에 누가 현재 로그인 되어 있는지 알 수 없다. 그래서 사용자가 어떤 활동을 했는지 알게 되어 개인 침해의 위험이 적음. 그렇기 때문에, 헬스케어, 은행, 보험과 같은 돈과 관련된 회사에서는 세션을 사용하는 것이 더 낫다. 또한, JWT는 사용자에게 데이터가 보인다는 점을 기억해야 한다. (anyone can read it or get an idea of how data or ID is structured, or how many rows data has, which is not the case for sessions as the data is not visible to users.)
대역폭 소모Bandwidth Consumption
세션은 대역폭을 적게 차지하지만, jwt를 기반으로 하는 인증방식은 대역폭을 더 많이 차지한다.
그 이유는 토큰은 점점 길어지는 경향이 있고, 매 요청마다 이 signature를 보내야 하기 때문
반대로, 세션 및 쿠키를 사용할 때는 session ID만을 보내기 때문에 아주 작다.
Revoking Roles and Privileges in JWT and Session-based Systems
회사에서 일어나는 많은 침해?는 내부 사람이 데이터를 훔치거나 이상한 짓을 해서 일어나는 경우가 많다. 그렇기 때ㅔ문에, 즉시, 권한을 무효화시킬 수 있는 것은 중요함.
예를 들어, 한 사람이 관리자 권한을 가지고 있다고 하자. 그리고 토큰은 10분 혹은 그 이상 유효하다. 어떤 이유에서든, 그 사람이 더 이상 권리자 권한을 가지고 있길 원하지 않을 때, 세션을 사용한다면, 그 사람의 권한을 바로 무효화시키는 것이 쉽다. 하지만 JSON 웹 토큰을 사용할 경우에는 어려울 수 있다.
JWT의 이점
Scalability
- 세션의 이슈 중 하나는 확장성이다. 세션은 메모리에 저장되고 서버는 애플리케이션을 다루기 위해 복제 되어야 하기 때문에, 애플리케이션의 확장성에 한계가 생긴다. 반면, JWT는 stateless이기에 더 높은 확장성을 가진다.
만약에 로드 밸런서를 사용한다면 이용자를 다른 여러 개의 서버에 보낼 수 있다. 어디에도 state나 session data를 저정하고 있지 않기에! 그래서 구글이나 페이스북과 같은 gigantic scale workloads를 가진 회사에서 쉽게 사용 할 수 있다.
Maintainability
세션의 단점 중 하나는 유지 보수성이다. 세션은 계속 유지 보수가 되어야 하기 때문
어떤 사람의 서버 어딘가에 유저가 인증할 때마다 레코드가 만들어져야 한다. 더 많은 이용자가 인증할 수록 서버에 오버헤드를 더 많이 일으킨다. JWT에는 유지 보수성이 필요가 없다.
Multiple Platforms and Domain
다양한 기기에서 사용하려고 할 때, scale이나 expand해야 한다.
그렇게 되면 cross-origin 이라던지 생각해야 할 게 많지만,
JWT의 경우, CORS 신경 쓸 필요 없이 모든 기기, 애플리케이션에 데이터 제공이 가능하다.
유효한 유저가 유효한 토큰을 가지고 있는 한, 데이터와 리소스는 어느 도메인으로부터 사용 가능하다.
Platform Independent
jwt를 이용해, 제 3의 애플리케이션에 선택적 권한을 허용해줄 수 있다.
예를 들어 다른 애플리케이션과 권한을 공유하고 싶은 애플리케이션을 만든다고 하자. (예를 들어, 페이스북에서 본 비디오를 인스타그램 친구에게 공유) 유저 데이터에 접근할 수 있는, 다른 애플리케이션에 특별한 토큰을 넘겨주는 API를 만들 수 있다.
'꼬꼬마 개발자 노트 > Spring' 카테고리의 다른 글
서블릿, 동시 요청 멀티쓰레드 (0) | 2022.03.23 |
---|---|
객체 지향 설계와 Spring (0) | 2022.03.22 |
공부필요한 내용 (0) | 2021.07.10 |
Spring Boot Tutorial | Full Course [2021] (7) (0) | 2021.06.11 |
Spring Boot Tutorial | Full Course [2021] (6) (0) | 2021.06.11 |