백엔드에 로그인 기능이 있고 브라우저에서 email/pw 를 넘긴다.
백엔드에서 DB에서 일치하는 이메일과 비밀번호가 있는지 확인하고
있으면 그 유저가 로그인 했다 기록을 한다.( 백엔드 메모리 세션에 저장 )
createProduct 에 price, name, description 등 아이디와 함께 넘겨준다.
백엔드에서는 메모리 세션과 비교하여 로그인 확인 과정을 거치고 상품 등록
( 없으면 에러메시지 )
일을 하는것은 CPU
저장해두는 것은 메모리(램)
메모리를 초과하는 요청이 들어오게 되면 서버가 터진다.
해결방법:
요즘은 scale out을 많이 한다.
백엔드 컴퓨터가 상태정보를 가지고 있다. 컴퓨터 마다 정보가 다르기 때문에 - satefull
statefull 상태에서는 scale out 하기 어렵다.
상태를 없애준다. - stateless
하나의 컴퓨터의 상태를 없애는데 DB(Session)에다가 저장을 한다.
그리고 scaleout을 한다.
예전의 memory에 있던 정보가 DB로 넘어오게 됐다.
이렇게 되면 많은 정보들이 DB에 몰리게 된다.
DB의 과부화를 막기 위해 몇개를 더 만드는 것은 어렵다.
해결 방법: 나눠서 받는다.
User 테이블의 row를 나눈다 - 수직파티셔닝
User 테이블의 column을 나눈다 - 수평파티셔닝(= 샤딩 )
예를들어 1~100번은 1번 DB에 저장 101~ 200번은 2번DB에 저장
하는 식으로 DB를 분산시킬 수 있다.
DB는
속도가 떨어지다 보니깐 DB기반 메모리 Redis에 넣어 두어 부화를 분산한다.
토큰아이디만 가지고 저장을 안하고도 나머지 내용들을 알 수 있는 방식은 없을까?
예) 비밀번호를 암호화한다. 1234 -> abcd
복호화한다. abscd -> 1234
객체를 암호화 시킨다. JSON Web Token - JWT 토큰
복호화 할 수 있는 키만 가지고 있으면
이렇게 하면 DB가 필요가 없어진다.
email 과 pw를 입력하여 백엔드에 요청하면 login에 들어있는 객체정보를 암호화하여 브라우저에 던져 준다.
암호화된 JWT를 브라우저의 GlobalState에 저장을 한다.
createProduct를 하려고 할 때 브라우저에서 JTW를 넘겨주고 백엔드에서는 암호화 된 것을 복호화하여 DB로 가서 상품을 등록한다.
인가에 집중을 해야한다.
accessToken 로그인인증 받을 때 전달해주는 토큰 ( JWT와 상관이 없고 JWT를 accessToken 으로 사용할 것이다.)
JWT 토큰 키는 백엔드에 있지만 누구든지 열어볼 수 있다.
3600이 차이나는데 한시간마다 로그인을 해줘야한다. 그걸 막는 것은 refreshToken 이다.
누구든 열어볼 수 있지만 조작된 키인지 검증을 할 수 있다.
중요한 데이터는 넣으면 안된다.( 간단한 정보: ID와 만료시간 정도 )
state에 저장되고 인가가 필요한 Api 를 요청하는 방법을 알아 보겠다.
HTTP HEADERS 에 JWT를 넣어준다.
Bearer는 문자열이다. 토큰인증 관련해서는 Bearer를 쓰는것이 관례이다.
백엔드개발자분이 설정
네트워크창 여기에 들어가게 된다.
- 양방향 암호화 ( 암호화를 하고 복호화를 할 수 있었다 )
- 단뱡향 암호화 ( 암호화를 했는데 복호화를 못한다. -hash )
암호화가 되어있으면 해커에게 털려도 괜찮지만, 해커들은 암호화된 키의 알고리즘을 파악해 복호화하여 털린다.
그래서 단방향 암호화를 사용한다.
예를들어 2자리 수로 묶어 10을 나눈 나머지로 암호화를 하면 복호화 할 수 없다.
18, 28, 38 모두 8이 된다.
그래서 비밀번호 찾기를 했을 때 비밀번호가 나오지 않고, 다시 만들어야 한다.
하지만, 해커들은 hash에 있는 모든 경우의 수를 가지고 비밀번호를 알아낸다. ( 레인보우 테이블 )
최근에는 salt를 넣어서 경우의 수를 더 많이 만들어 준다.