로그인의 역사
로그인은 시간이 지남에 따라 방식이 많이 달라졌다.
옛날 로그인 방식
- Browser에서 로그인 요청! (이메일, 비밀번호 기재 -> 로그인 버튼)
- 데이터가 Backend의 로그인 API로 들어옴
- DB의 USER 테이블 찾아서 요청받은 로그인 정보가 있는 지 조회
- 값이 맞으면 Backend 컴퓨터에 로그인 = true 값으로 저장해놓음
------- 위 과정을 인증 이라고 함
- 인증: 로그인 데이터를 입력해서 로그인 증표를 받는 과정
- 인가: 로그인 증표를 던져서 실제 데이터를 받는 과정
===> 인증은 1번만 하면됨 / 인가는 계속함로그인 방식의 변경
-
유저가 많아지면 backend 컴퓨터, 메모리에 너무 많은 무리가 가게 됨
=> 메모리를 늘리자! (Scale up!) -
아무리 메모리를 늘려도, Backend 컴퓨터가 꺼지는 등, 버틸 수가 없었다.
-
그러면 Scale up 하지말고, 컴퓨터 대수를 늘려서 꺼지는 리스크를 최소화하자!
(Scale out!) -
1번 컴퓨터로 인증받고 2번 컴퓨터로 인가요청하면 인증이 안받은 것으로 처리되는 문제 발생
-
그러면 로그인 정보를 백앤드에 저장하지말고 DB에 저장하자!
-
백앤드에서 DB로 로그인 정보를 옮김으로서
(Stateful 상태에서 => Stateless로 변경함 => Scale out 성공)
-
유저가 많아지면 "인가"를 계속 하게 되는데, 백앤드 컴퓨터를 늘렸지만
DB는 늘어난게 아니라서 DB쪽에서 병목현상이 발생함
- Bottle neck (병목현상) - 특정 구간에서 속도가 정체됨- DB는 scale out 하기가 힘들다. 어떻게 하지?
- 테이블을 나누자! (수직파티셔닝 / 수평파티셔닝)
- 수직 파티셔닝 - 키값+데이터를 통째로 수직으로 잘라서 나누는 것
- 수평 파티셔닝 - 키값은 유지하고 데이터만 수평으로 잘라서 나누는 것 (샤딩이라고도 부름)-
DB는 컴퓨터가 꺼져도 데이터가 남기에 DISK I/O 속도가 느린데?
-
Redis를 DB로 써보자 (Ram 형태의 DB, 컴퓨터 끄면 데이터 날아감)
------- 오늘날 많이 사용하는 로그인 방식
-
Redis에도 저장안하는 방법은 없을까?
-
백앤드 컴퓨터에서 인증을 진행 후 암호화 시켜서 객체로 저장
인가 요청을 받으면 암호화된 데이터를 '복호화' 하여 '인가' 진행.----- Redis 안쓰고 암호화하여 저장하는 방법
- JWT 토큰 사용
(Jason Web Token : 유저 정보를 담은 객체를 암호화한 것)
- 유저 정보를 암호화시켜서 브라우저 저장소에 저장한다.
- 유저 정보를 요청하는 '인가'가 들어올 경우 백앤드에서 유저 정보를 '복호화' 하여
- 유저를 식별한 뒤 API 실행.
JWT
Encoded - 암호화 된...
Decoded - 복호화 된...
iat = Issued at ( 발행 시간)
Decoded - Header(알고리즘 이름) / Payload(데이터) / Signature (비밀번호)- 사실 JWT 토큰은 누구든지 열어볼 수 있다. (그냥 jwt.io 가서 붙여넣기하면됨)
- 절대 중요한 데이터 저장 X
- 하지만 조작하려면 비밀번호가 필요함
local storage (브라우저 전용) - 보안문제 있음
- 브라우저 껐다켜도 데이터 남아있음
session storage (브라우저 전용) - 보안문제 있음
- 브라우저 껐다키면 데이터 없어짐
cookie = 백앤드와 브라우저 사이어세 데이터 주고 받을 때 사용
자동으로 데이터 들어감암호화
양방향 암호화
암호화를 진행한 후, 복호화가 가능한 암호화 방식
단방향 암호화 (HASH)
암호화 후에, 복호화가 불가능!
단방향 암호화 진행하여도, 무차별로 암호를 대입하는 bruteforce에 취약함.
알고리즘에 대한 input/output - rainbow table
임의의 키값을 추가하여 그 상태로 단방향 암호화를 반복하는 것 (salt를 추가한다)
<- 오늘날의 보안 시스템 / bcrypt라는 라이브러리 사용함.
