6월 8일 학습 목표
로그인 방법이 굉장히 많다!
=> 사용량이 적은 서비스에서 활용하는 방식
브라우저는 frontend 서버에서 html, css, js를 다운받는다
로그인 정보를 입력한 뒤 로그인하기 버튼을 눌러 백엔드에 api를 요청한다 (정보를 보냄)
백엔드에서는 user table에 Email, pw가 db에 일치하는 정보가 있는지 확인한다
정보가 있으면, 회원 정보와 로그인 했다는 정보를 백엔드 컴퓨터의 메모리에 저장한다
-
메모리 : 임시 저장소 (메모리 세션에 로그인 정보를 저장)
-
디스크 : 영구 저장소
⭐️ 실무에서는 로그인 만료 시간을 준다. 한 번 로그인했다고 영원히 로그인 x - 보안관련백엔드는 브라우저에 세션 아이디를 전달해준다 => 인증과정 (Authentication)
브라우저는 세션 아이디를 저장한다 (쿠키)로그인이 필요한 api를 요청하게 되면? (ex. createProduct)
브라우저가 보내는 것
1) 상품 정보, 가격, 설명 등
2) 세션 아이디 (uuid)
백엔드는
메모리 세션에 있는 정보를 확인한다 -> 세션아이디를 통해서 회원이 맞는지 확인, 로그인 상태가 맞는지 확인 = 인가(Authorization : 인증과정 이후)
y : 상품 등록 -> product Table로
n : error -> 만료시간이 다되어 인가에 실패하면? 다시 로그인창으로
=> 사용량이 많은 서비스에서 활용하는 방식
일하는 cpu, 각 요청을 저장하는 memory(렘)이 필요
한데 사용자가 많아지면 서버컴퓨터의 메모리 저장 공간이 부족해진다 -> 서버 터짐
-> 해결방법?
1) 서버컴퓨터의 메모리 증가시키기 (scale up)
2) 서버 컴퓨터를 나누어 감당함 (sclae out)
백엔드 컴퓨터가 상태정보를 가지고 있는 것 (stateFul) - 상태를 동기화하기 어렵기 때문에... scaleout이 어려워짐. -> 그럼 상태를 없앨까? (stateless) -> DB에 세션 table을 만들어 저장 -> 그럼 sclaeout 가능
-> 그럼 db는 부하를 감당할 수 있을까? -> db컴퓨터를 늘리나?(쉽지 않음)
나눠서 담는다!
수직 파티셔닝과 수평파티셔닝(=샤딩)
ex.
1~100은 1번 데이터베이스, 101~200은 2번 데이터 베이스
부하가 분산되는 모습
매번 인가를 처리할 때마다 db를 긁어야
하기 때문에 속도가 떨어진다 (디스크에 저장되어있음)
=> 메모리 기반 Redis에 넣어보자 (속도가 빨라진다)
토큰아이디를 주고 받고, 확인하는 과정임
⭐️ 또 다른 로그인 방법
회원 정보를 저장하지 않고 토큰아이디만 가지고 정보를 알 수 있는 방법?
암호화와 복호화
로그인 정보에 적용하면?
db Redis에 저장할 필요가 없다
세션아이디(토큰아이디) = 암호화 결과 -> 복호화하면 회원정보 (Json Web Token = JWT)
총정리
브라우저가 eamil, pw정보를 입력하고 로그인 버튼을 통해 백엔드에 로그인 api를 요청한다
백엔드는 Email,pw가 db에 있는지 확인하고 Json web token을 만든다.
이 객체를 암호화 시켜 전달한다.
이 암호를 글로벌 스테이트에 저장한다.
상품등록 (로그인이 필요한 api) api를 요청할 때, 같이 전달한다.
백엔드에서는 복호화하여 회원이 맞고, 로그인 기간이 맞으면 상품 등록 완료
accessToken 인가가 필요할 때 들고다니는 토큰
우리는 JWT 토큰을 들고다닐 것이기 때문에 aT라고 부르는 것
실습
로그인하면 나오는 accessToken을 state에 저장해야 함
저장된 state를 가지고 인가가 필요한 api를 요청할 때 사용한다
암호화, 복호화하는 key는 백엔드에 저장되어 있음 -JWT 누구든지 열어볼 수 있다?!
jwt.io에서 토큰 내용을 열람할 수 있다!
=> refreshToken을 사용하여 로그인 유지 시간을 늘린다
누구든지 열어볼 수 있지만,
조작된 데이터인지, 조작되지 않은 데이터인지 구분 할 수 있다 -> 백엔드에서 key로 검증
DATA에다가 중요한 정보를 넣으면 안된다
간단한 정보만!!!!(카드정보 주소 등 xxxx, id나 만료시간 등만)
accesstoken은 HTTP HEADERS에 첨부한다!
Bearer 뒤에 로그인 token 넣기 - (백에서 만든 규칙대로...)
(백엔드에서는 Bearer뒤에 문자열을 가져가서 복호화)
암호화
- 양방향 암호화 : 암호화 가능, 복호화 가능
- 단방향 암호화 (hash) : 암호화 가능, 복호화 불가능
비밀번호 유출을 막기위해 비밀번호를 암호화해서 저장한다
user db가 유출되더라도 pw 유출되지 않도록 (서비스마다 알고리즘이 다름)
해커들은 암호화된 table을 복호화 할 수 있다 ㅠㅠ 그래서 복호화가 안되는 단방향 암호화를 해버린다
해시된 비밀번호를 저장하고, 원본은 저장하지 않는다
단방향 암호화 : 앞에서 부터 2개씩 끊어가지고 10으로 나눈 나머지를 적어놓은 것, 다대일 관계로 복호화가 불가능
레인보우 테이블로 다대일관계를 해결하려는 해커들도 있음 ㄷㄷ
이를 막으려고 더 어려운 알고리즘이나 salt까지 추가하기도 함
따라서 비밀번호는 찾을 수가 없다!
새로 비밀번호를 만들어야 정상적인 사이트!!!!
aT는 recoil활용!
오늘 공부를 돌아보며
알고리즘 1문제 못푸신 (원래 목표가 3개였다^^)
