Login History
First
브라우저에서 특정 email과 password를 가지고 로그인을 하게되면 백엔드로 loginAPI 요청이 날라가게 되고, 백엔드에서는 해당 유저가 있는지 DB에 확인 후 있으면 session에 저장하게되요.
그 후 특정한 id를 부여해서 브라우저로 보내줘요.
이렇게 보내진 id는 해당 유저가 뭔가를 요청할 때 본인이 누군지 식별 할 수 있도록 id를 함께 넣어서 보내줘요.
문제점
- 백엔드 서버가 꺼질경우 기존에 로그인을 했더라도 인증이 날라가요(재로그인을 해야하는 문제 야기시킴)
- 유저의 정보(Id)를 백엔드 서버로 받다보니 한번에 여러명의 정보를 받기엔 한계가 있었어요.
해결방법
Scale-up : 컴퓨터 하나로 메모리를 증가
Second
이렇게 백엔드 컴퓨터의 성능을 올려주었음에도 불구하고 더 많은 유저의 접속이 동시 다발적으로 일어나면, 여전히 서버의 부하를 초래했어요.
그래서 나온 방법으로 백엔드 컴퓨터를 복사하는 방법 이었어요.
이 방법은 유저의 정보가 담기는 백엔드 컴퓨터를 복사해 여러대의 컴퓨터로 백엔드 서버의 부하를 분산해주었어요.
해결방법
Scale-out : 컴퓨터 하나로 하는게 여러대를 사용하며 트래픽을 분산
- 문제점 1번에 로그인 인증이 들어가 있는데 2번으로 DB를 요청하게되면 인증이 없기에 사용할 수 없어요
(특정 세션이 정보를 가지고 있는 상태를 stateful이라고함)
(특정 세션이 정보를 지운 상태를 stateless라고함)- DB는 한곳으로 몰리기에 병목형상이 일어남(똑같은문제 반복)
Third
이 방법은 위의 session을 scale-out해오지 못하는 문제점을 보완한 방법이자 DB에 부하가 몰리는 병목현상을 해소한 방법으로, 현재 많이 쓰이고 있는 방법이에요.
session을 복사해오지 못하자 사람들은 로그인 정보를 DB에 저장하기 시작했습어요.
하지만 결국 이것도 백엔드 서버의 부하가 DB로 옮겨진 것 이기 때문에 DB의 부하를 초래해요.
보완을 위해 “DB를 복사하면 안되나?” 라고 생각하셨을 수 있지만, DB를 복사하는 방법은 비용문제가 발생하기 때문에 비효율적이에요.
파티셔닝을 수직으로 자르면 수직 파티셔닝이라 하고 수평으로 자게 되면 수평 파티셔닝(샤딩)이라고 불러요
그렇게 나눈 파티셔닝을 백엔드에서 각 해당하는 DB로 전송하게 되어 병목현상을 해결했어요
따라서 위의 문제점은 데이터를 쪼개면서 해결하게 되요.
해결방법
Redis : 메모리에 저장해두는 임시 데이터 베이스
DB에다가 저장만 하다보니 Disk I/O로 너무 느린 형상이 일어나서 Redis(메모리 기반)
에 저장을 하고 사용을 하는 방식을 썼어요 다만 Redis는 접속을 종료하면 데이터가 다 날라가는 단점이 있어요
Fourth (현재 많이 사용하는 방식)
JSON Web Token(JWT)
“로그인 정보를 굳이 서버나 DB에 저장해야 할까?” 생각을 하고 탄생한 것이 JWT 토큰이에요.
JWT 토큰은 유저 정보를 담은 객체를 문자열로 만들어 암호화한 후 암호화된 키(accessToken)를 브라우저에 줍니다.
받아온 암호화된 키는 브라우저 저장소에 저장해두었다가 유저의 정보가 필요한 API를 사용할 때 보내주게 되면,해당 키를 백엔드에서 복호화해서 사용자를 식별한 후 접근이 가능하도록해요.
JWT 토큰에는 해당 토큰이 발급 받아온 서버에서 정상적으로 발급을 받았다는 증명을하는 signature를 가지고 있어요.
따라서 사용자의 정보를 DB를 열어보지 않고도 식별할 수 있게 되었어요.
암호화
우리가 로그인을하고, 로그인 정보를 fetch해왔을 때 브라우저에 비밀번호를 fetch 할 수 없어야 해요.
즉, 비밀번호를 알아내는게 불가능해야해요.
DB에 있는 비밀번호를 알아낼 수 있게되면, 해킹을 잘하는 사람이 DB를 해킹해왔을때 유저의 비밀번호를 알아낼 수 있게 되면 민감한 정보에 접근이 가능하게되요.
암호화의 두가지
-
양방향 암호화
양방향 암호화는 JWT같은 복호화가 되는 암호화를 말해요.
즉, 암호화와 복호화 모두할 수 있는 암호화 입니다. -
단반향 암호화 (해시:
hash)
단방향 암호화는 암호화는 되지만 복호화는 안되는 것을 의미해요.
민감한 정보를 저장할때는 해킹을 당해도 알아볼 수 없도록 단방향 암호화를 사용하여 저장하게되요.
hash의 중요성
레인보우테이블은 모든 경우의수를 담아둔 해커의 테이블이에요.
경우의수에서 될때까지 하는것을 무차별 대입공격 Brute Force Attack이라고 불러요
무차별 대입공격을 방지하기위해 쓰는법
Hash(키 스트레칭)
ex) 275719 —암호화—> 779
앞에서 부터 2개씩 끊어가지고 10으로 나눈 나머지를 적어놓은 것이 779가 된다면.
10으로 나눴을 때 나머지가 7이 되는 숫자는 27,37,47 등등 너무나도 많기 때문에 원래 정보가 뭔지 모르게 만드는 것 이에요
