220412_TIL

오늘의 목표

1. 로그인을 이해하려면 역사를 알아야됨 Login
2. JWT토큰?? JWT
3. 로그인 인증 토큰은 어디에 저장해? Recoil

1. 로그인 방식

가. 브라우저에 요청하면 백엔드에서 session을 계속 추가하는 방식

이런 방식으로 하면 session에 계속 쌓이고 api요청이 일어나면 트래픽 과부하가 생기고 메모리를 늘리는(스케일업)이 필요함

계속해서 할 수 없기에 똑같은 컴퓨터 한개씩 늘리는 작업(스케일 아웃)을 함

스케일 아웃을 했을 때 요청한 api가 다른 B컴퓨터에 들어오면 요청이 안된 것으로 오해하게 됨
session에 저장된 상태 가지고 있는 컴퓨터를를 stateful이라고 함
session에 저장된 상태를 가지고 있지 않은 컴퓨터를 stateless라고 함
그래서 부하를 분산하기가 쉽지 않음

나. 부하를 조정하기 위해 백엔드컴퓨터를 여러대 만듬

모두다 stateless상태로 만들고 session을 db컴퓨터에 저장함
그리고 db에 state를 계속 요청함

이러면 db컴퓨터에 부하가 몰려 완벽한 해결책이 아님

db를 늘리면?
데이터를 계속 복사해야 하니까 비효율적임

다. 테이블을 나누는 방법

수직 파티셔닝
수평 파티셔닝

파트를 나눠서 각각의 디비에 저장하는 방법
이는 디스크에 저장해서 영구적으로 저장하기 때문에 요청이 오면 무조건 db디스크를 왔다갔다 해야되서 좀 느림

이걸 안할라고?
redis를 이용해서 메모리에 저장함
redis를 이용해서 저장하는 것이 요즘 사용하는 방식 2가지중 1번째

2. 2번째 방식

redis에 저장안하고 사용하면 더 효율적일 수도?

객체를 만들어서
{
id :aaa
name : 철수
exp: ~2022
}

여기서 id를 지우고 name, exp를 암호화 하면 wqorqrqk2131412io같은 난수로 나옴
이를 토큰 아이디로 쓰고 필요시 복호화 하면 데이터가 튀어나옴!!
이른 JSON WEB TOKEN이라고 JWT라고 함
JSON은 Java Script Object Notation

브라우저 요청 백엔드 타고 db에서 확인 후 백엔드에서 JWT 발행하고 API요청 들어오면 JWT복호화 후 확인

JWT사이트
1. SIGNATURE
서명
2. PAYLOAD
issued at

JWT = access Token은 아님
access Token 방식중 하나가 JWT임

access Token은 길어야 2시간 정도 유효기간을 가지고 있음 이를 탈취해서 api요청하면 해킹이라서
그러면 1시간마다 다시 로그인해야하나? 너무 불편함
그래서 나온 개념이 refreshtoken이 있음

JWT는 누구든지 아무나 열어볼 수 있음 그래서 중요한 정보는 저장하면 안됨
그런데 조작은 불가능함
만들어졌을 때 서명된 내용하고 일치하는지 안하는지

3. 암호화의종류

양방향 암호화
암호화하고 복호화 할 수 있는 방식

단방향 암호화(Hash)

암호화한 내용을 복호화 할 수 없는 것
ex)
172638 -> 768
두자리씩 10나눈 나머지
근데 이런걸 또 모든 경우의 수를 다 적은 레인보우 테이블이 있음
그래서 해쉬화 한 암호를 한 번 더 해쉬하고 이지랄 함

결론 완벽한 해킹 및 보안은 없다.

헤더부분에 JWT토큰을 첨부해서 보냄

play그라운드 밑에 HTTP HEADERS에서 실습 가능
{
"Authorization" : "Bearer 어세스토큰"
}
Bearer는 그냥 관례임

인증 : Authentication
로그인으로 어세스 토큰 받아오는 것
이메일과 비번을 날려주고
일정시간 동안(어세스토큰 만료시간) 1번만 하면 됨

인가 : Authorization
이미 받은 토큰을 가지고 상품을 등록하거나 결재하거나 정보를 받아오거나 하는 api를 사용할 때 이사람이 누군지 확인하는 과정

4. 적용하기

JWT를 글로벌 state에 저장하기

400 잘못 요청했을 때
404 없는페이지요청
500 서버가 이상해