[로그인 프로세스] 로그인의 역사

성지혜·2022년 10월 9일
0

📍 로그인의 역사

브라우저에서 email과 password로 로그인 -> 백엔드로 loginAPI 요청이 날아감
-> 백엔드: 해당 유저가 있는지 DB에 확인 후 있으면 session에 저장
-> 그 후 특정한 id를 부여해서 브라우저로 보냄
-> 이렇게 보내진 id는 해당 유저가 뭔가를 요청할 때 본인이 누군지 식별할 수 있도록 id를 넣어 보내줌

백엔드 서버로 여러 유저의 정보(id)를 받기엔 한계가 있기에 백엔드 컴퓨터를 scale-up해줌.

💡 scale-up이란?

  • 컴퓨터의 성능(cpu,memory등)을 올려주는 것

💡 session이란?

세션에 값을 저장한다고 할때 세션은 브라우저를 의미,
-> 즉 접속중인 웹 서버에 저장됨.

ex) 로그인을 하면 브라우저가 켜있는 동안은 로그인이 유지되다가 브라우저를 종료하거나 timeout이 되면 로그아웃이 된다.

로그인 해놓고 다른 브라우저를 켠다거나 하면 로그인이 안되어있음.

하지만 더 많은 유저들이 동시에 접속한다면? => 서버 과부하 초래

따라서 백엔드 컴퓨터를 복사하여 서버의 부하를 분산

💡 scale-out이란?

-> 똑같은 성능의 컴퓨터를 추가하는 것
-> 세션까지는 추가가 안되기에 로그인 정보는 없음

session을 복사해오지 못한다면? DB에 로그인 정보를 저장
-> 하지만 이것도 결국 부하를 초래 어떡하지?
-> DB도 scale-out 하듯 추가하자!
-> 그건 비용문제가 발생
-> 위의 문제는 데이터를 쪼개며 해결

💡 데이터 베이스를 쪼개는 2가지 방법

  • 수직으로 쪼개는 수직파티셔닝
  • 수평으로 조개는 수평파티셔닝(샤딩)

하지만 여기에도 문제 발생
-> DB는 컴퓨터를 껏다 켜도 날아가지 않기 때문에 데이터들이 disk에 저장됨
-> 따라서 안전하지만 느리다. 결국 이렇게 disk에 저장된 데이터를 추출해 오는 현상을 DB를 긁는다(scrapping)고 표현
-> 이를 해결하기 위해 Redis라는 데이터베이스에 저장 가능
-> redis는 메모리에 저장하기 때문에 위의 문제점 해결

💡 Redis

-> 메모리에 저장해두는 임시 데이터 베이스

이렇게 저장된 ID(토큰)을 다시 브라우저로 돌려줌
돌려받은 토큰은 브라우저 저장공간에 토큰을 저장해두고 어떤 행동을 할 때 토큰을 보내주어 사용자가 누구인지 식별가능

  • stateless -> 백엔드 컴퓨터에 상태를 가지고 있음

JWT 로그인

"로그인 정보를 굳이 서버나 DB에 저장해야 할까?"
-> JWT 토큰의 탄생

JWT 토큰은 유저 정보를 담은 객체를 문자열로 만들어 암호화한 후 암호화된 키(accessToken)를 브라우저에 준다.
-> 받아온 키는 브라우저에 저장
-> 유저 정보가 필요한 API 사용시 보내줌
-> 해당 키를 백엔드에서 복호화해서 사용자를 식별 후 접근가능하게 함
-> JWT 토큰에는 해당 토큰이 발급 받아온 서버에서 정상적으로 발급을 받았다는 증명을 하는 signature를 가지고 있음
-> 따라서 사용자의 정보를 DB를 열어보지 않고 식별가능

JWT의 단점

다음사이트의 Encoded 부분에 accessToken을 넣어보면, 토큰 정보가 decoded 부분에 모두 보임.
-> 암호화했지만 누구든 열어볼 수 있다...
-> 중요한 데이터는 JWT 토큰에 저장해서는 안된다.

profile
많이많이 시도해보기

0개의 댓글