로그인 프로세스

옛날 방식 

DB에 id/pw이 있으면 session에 로그인 기록을 저장 sessionid를 클라이언트에 보내줌 클라이언트와 sessionid를 통해서 인증,인가함
문제점 :  백엔드 서버 사용자가 늘어났을 때 scale out(서버 증설)시 stateful한 상태가 되게된다. -> session 정보를 DB에서 관리를 해준다.

문제점 : DB에 I/O가 늘어서 부담이 늘어남 -> DB를 늘리면 모든 DB에 같은 정보가 들어가야함 (더 문제) -> DB를 쪼갠다.

DB를 어떻게 나누나?

수직 파티셔닝

수평 파티셔닝 = DB 샤딩 ex) 1~10000을 DB1, 10001 ~ 20000을 DB2로 나누는

메모리 vs 디스크 : 영구성, 속도

메모리 전용 DB : Redis = DB를 긁는게 느려서 메모리에 저장하는 방식 

각각의 Redis에 토큰 정보를 저장하고 조회하는 방식

JWT Token : 최근 방식

Json Web Token 객체타입으로 {email : adlfal, isLogin: true}를 암호화와 복호화를 통해 로그인 확인하는

JWT의 복화와 관련은 백엔드서버가 가지고 JWT를 Br과 B에서 서로 주고받으며 B에서 복호화함으로 로그인을 인증함

-> DB를 거의 안가고도 로그인을 검증 할 수 있음

 

암호화

1. 양방향 - 복호화 가능

2. 단방향 - 복호화 불가능

비밀번호는 단방향으로 암호화 해야함 = Hash

해커들이 발전하며 Hash를 경우의 수를 돌리며 Ranibow Table을 만듦 -> salt라는 현재 해결책을 사용함

salt : Hash 중간 임의의 문자를 넣어줌