오늘은 로그인의 역사에 대해 배웠다!
첫번째
로그인 요청시 백엔드 컴퓨터에서 데이터를 받고, 데이터베이스에 회원가입한 유저가 맞는지 찾는다.
그 후 맞다면 로그인 여부 및 유저 정보ID를 백엔드의 메모리 세션에 저장 후 브라우저 쿠키에 정보ID를 저장한다
조회 요청시 쿠키를 함께 벡엔드로 보내 해당 ID의 로그인 여부로 데이터 조회를한다
두번쨰
첫번째 방식을 사용중 사용자가 많아짐에 따라 백엔드 컴퓨터의 메모리가 부족 하여 컴퓨터 대수를 늘리고 정보ID 및 로그인 여부를 데이터베이스에 저장하여
백엔드 컴퓨터의 부하를 분산했다
세번쨰
이렇게하니 데이터베이스에 병목현상이 생김
그래서 데이터베이스도 늘리고 데이터를 쪼개서 저장했다
그리고 데이터베이스는 DISK에 저장하기 때문에 느려서
해당 정보ID 및 로그인여부는 데이터베이스의 Redis라는 메모리에 저장
네번쨰
로그인 정보를 굳이 서버나 DB에 저장해야 할까? 라는 생각에
백컴퓨터에서 로그인 정보를 객체로 받고 암호화 시키니 정보ID 처럼 나옴 그걸 accessTokenJWT라고 함 그걸 쿠키에 저장
그리고 조회를 할때 해당 암호화키를 복호화를 하여 해당 겍체에 로그인이 true면 데이터 베이스에서 데이터를 꺼내줌
JWT토큰은 누구든지 볼수있으므로 중요정보는 저장하지 않는다
하지만 JWT토큰은 조작은 불가하다
조작하려면 서명(비밀번호를 입력해야함)
-
양방향 암호화
양방향 암호화는 JWT같은 복호화가 되는 암호화
즉, 암호화와 복호화 모두할 수 있는 암호화이다 -
단방향 암호화(hash)
단방향 암호화는 암호화는 되지만 복호화는 안되는 것을 의미
890907을 두자리씩 10으로 나누면 997이 됨
이걸 여러가지 조건으로 수없이 많이 하는 방식이다
