밸~하!
밸로그 여러분 안녕하세요!
오늘의 주제는 로그인의 역사와 어떻게 진행되는지 알아볼수있도록 하겠습니당
1.로그인을 이해하려면 역사를 알아야돼!
먼저 로그인이 어떠한 과정을 통해서 이뤄지는지 알아볼수 있도록 하겠습니다!
브라우저가 프론트엔드 컴퓨터에서 전달해준 HTML,CSS,JS파일을 읽습니다
이때 아이디와 비밀번호를 입력받게되고
입력받은 정보들을
백엔드 컴퓨터로 전달을 해주게되고
백엔드 컴퓨터는 이 데이터를 DB로 보내 DB에서 검증을 하게 되고
로그인이 되었을 시 백엔드 컴퓨터에서는 로그를 저장하게 됩니다!
그럼 어디에 저장을 하게되나!
바로 메모리 세션이라는 곳에 저장을하게 되는데요!
저장공간에 대해서 잠깐 이야기드리겠습니다
저장공간은 크게
디스크와 메모리로 나뉘어 지는데요
메모리는 변수들 즉 껏다가 켰을때 사라지는 데이터들을 저장하고
디스크의 경우 엑셀파일같은 파일들을 저장하게 됩니다!
다시 돌아와서
백엔드컴퓨터에서는 메모리 세션에 저장을 한 이후
브라우져에 세선아이디를 전달해주게 되는데요!
이부분을 인증(Authentication)이라고 합니다!
이때 전달받은 브라우져는 이 세션아이디를 저장공간에 저장하게 됩니다
브라우저의 저장공간은 크게 4가지가 있는데요
변수,LocalStorage와 SessionStorage,cookie등이 있습니다!
변수는 저희가 알고있는 const와 같은것입니다
다시 돌아와서
브라우져에서는 이 저장공간에 저장했던 세션아이디를 백엔드 컴퓨터에 다시 전해주게되고
백엔드 컴퓨터에서는 세션아이디가 있는지를 확인한 이후 인가 곧 Authorization(인가)을 주게됩니다
인가를 주게됬을때 메모리에 저장을 하게 되니 메모리를 늘리게 됩니다!
이것을 scale up이라고 합니다
하지만 이것도 한계가 존재하기때문에
과도한 트래픽 발생시
여러개의 백엔드 컴퓨터를 사용해서 여러개의 컴퓨터에 분산해서 유저들을 받는 방법이 생겼습니다
자 그럼 어떻게 트래픽을 분산시킬수 있을까요??
알고리즘을 사용하면 됩니다
먼저
least connection이라는 알고리즘이 있습니다
바로
백엔드 컴퓨터의 접속컴퓨터를 탐색하여 적은 접속이 있는 컴퓨터에 접속요청을 보내주는 방식입니다!
또 다른 알고리즘으로는
round robin이라는 알고리즘이 있는데
이 알고리즘의 경우에는 모든 백엔드 컴퓨터를 순차적으로 돌려서 로그인을 하게 하는 방법이 있습니다!
물론!
이것말고도 여러가지 방법들이 있지만 대표적으로 이 두가지를 많이 채택하고있습니다!
하지만 문제가 있습니다
이렇게 여러개의 백엔드 컴퓨터를 사용하게 되면
다른 컴퓨터를 사용했기때문에
메모리 세션에 기존에 회원가입했던 정보가 없게되고
로그인이 안되는 경우가 발생하는 문제가 있습니다
이런부분을 어떻게 해결해야할지 고민을 해봐야한다는거죠
그럼 어떻게 해야 이부분을 해결할수 있을까요??
이런방법은 어떨까요??
각 컴퓨터의 메모리 세션에 저장을 하는것이 아니라
트래픽을 여러컴퓨터에 분산을 하고 받은 정보들을 DB에 저장을 하게 된다면??
해결할수있겠죠??
여러컴퓨터에서 한번에 받아서 사용할수 있으니까요!
그런데 이렇게 한다면은
병목현상이 발생해서 느려지게되겠죠?
그럼 이부분을 해결하기 위해 어떻게 해야할까요??
이런 생각도 해볼수가 있겠네요??
DB를 여러개를 복사하면 되는거 아니에요?
이것도 방법이 될수도 있겠지만
쉽지가 않습니다
왜그럴까요?
예를들어 한개의 DB에 100만개의 데이터가 있다고 한다면
복사하는게 어렵겠죠??
그렇다면 어떤 방식으로 DB부하를 분산할수 있을까요??
바로 파티셔닝이라는 방법이 있는데요
파티셔닝에는 두가지 방법이 있습니다
column을 기준으로 자르는 수직 파티셔닝이 있고
row를 기준으로 하는 수편파티셔닝 (샤딩)이 있습니다
이렇게 데이터를 잘라서 한개의 백엔드 컴퓨터가 한개의 DB에 넣게된다면
병목현상도 줄어들수 있게되고 트래픽 해결을 하게되서 훨씬 수월하게 데이터를 처리할수가 있는거죠??
하지만 이게 좋은 방법일까요??
이방법은 디스크에 저장이 되는 방법이지만
치명적인 단점이 있습니다
바로 속도가 느리다는건데요
메모리는 영구적이지는 않지만 빠르게 처리가 되는 반면
데이터베이스는 영구적이지만 처리가 느리게됩니다
이것을 해결하기 위해
메모리기반 DB
memcached ,redis라는 방법들이 나왔습니다
redis에 먼저 저장을 하게 되고 이것을 DB로 넘기게되면
처리가 훨씬 빠르겠죠?
하지만 DB에 저장이 되기전에 컴퓨터를 종료를 하게된다면 데이터들이 사라지게 되니 주의하셔야합니다
그래서 최근 사용되는 방법은
크게 두가지가 있는데요
메모리 기반 redis에 session정보를 저장하는 방법과
redis에도 저장을 안하는 방법이 나왔습니다!
그럼
도대체 redis에도 저장을 안하는 방법이 도대체 뭐야?!
라고 생각하실수있는데
지금 바로 설명드리겠습니다
바로!
암호화! 입니다
암호화를 사용하는 방법을 통해서 Redis에도 저장을 안할수 있게 된다는거죠
지금부터는 이 Redis에도 저장하지 않는 방법에 대해서 알아볼수 있도록 하겠습니다
가볍게 예시를 통해서 알아보겠습니다
예를 들어
비밀번호
182639 라는 신용카드의 비밀번호가 있다고 가정해봅시다
그런데 이것이 유출이 되게 된다면 위험하겠죠?
그래서 암호화를 시켜서 전달을 하게 되는데
암호화 알고리즘을 사용해서 이 데이터를 암호화 시킬수 있게됩니다
예를들어
1-a ,2 -b ,3-b ...등등으로 전달을 해주게 해봅시다
그럼
어떻게 될까요??
182639-> ahbfci이렇게 변경이 될겁니다
즉 암호화 알고리즘을 정의해놓고
객체에 이 알고리즘을 사용한다음
이 암호화된 정보를 sessionId로 사용을 하게되는거죠!
이런것을
바로
JWT토큰이라고 부릅니다
2.JWT란?
JSONWebToken이라고 합니다!
JSON은 객체이고 이 객체를 암호화 하여서
토큰으로 만들게 되고 이것을 통해서 빠른게 데이터를 저장할수 있게된다는거죠
최근 사용되는 방법은 이렇게 크게 2가지 방법이 있습니다!
이렇게 암호화와 복호화를 통해서 데이터를 전달하는 방식을
양방향 암호화라고 합니다!
양뱡향이 있다면 단방향 암호화도 있겠죠??
단방향 암호화는 어떤게 있을까요??
아까의 예시를 가져와서 다시 사용해보겟습니다!
182639라는 정보가 있습니다
이때
2개씩 끊어서 10으로 나눈 나머지를 저장하는 암호화 알고리즘이 있다고 가정했을때
18%10,26%10,39%10 ->869라는 값이 나오게 되곘죠?
이것을 복호화를 한다고 해봅시다
복호화가 될까요?>?
안돼겠죠?
왜요??
182639뿐 아니라 386699도 똑같이 869가 나오겠죠??
이렇게 多:1 방식을
뭉갰다는 의미의 Hash라고 합니다!
이렇게암호화는 가능하지만 복호화는 불가능한 방식을 단방향 암호화라고 합니다
다시 컴퓨터로 돌아와서
브라우저와 백엔드 컴퓨터와 DB가 있다고 생각을 해봅시다
이때 DB 안의 table 에 a@a.com 1234/b@b.com 6789 이런식으로 저장되면
노출이 되서 안되겠죠?
만약 이 DB를 관리하는 관리자가 퇴사했다고 하면 심각한문제가 생기겠죠?
뿐만아니라 해커가 이 Table의 정보를 가지고 갔다면 노출이 되겠죠?
이렇게 생각할수도 있겠죠?
그럼 이 table을 암호화 시키면 되겠다라는 생각을 할수도 있습니다
그럼 약간의 보안성은갖춰지겠지만
같은 패턴을 가지고 있다면은 알고리즘을 찾아내서 다시 복호화를 하겠죠?
그럼 원상복귀가 된것입니다
그래서 그다음에 나온것이
단방향 암호화입니다
그래서 단방향암호화를 했을때 복호화를 한 경우 알수가 없다는거죠
그러나 이때 모든 경우의 수를 for문을 통해서 돌리게되서 맞추게 되는거죠
그래서 최종적으로 나온방식이
이 곳에 임의의 문자열을 더해서 암호화를 하게되면 경우의 수가 너무 많기 때문에
그나마 보안이 좋은거겠죠?
그러나 이것도 언젠가는 뚫릴것이기에 지속적으로 발전된 기술이 나오고 있습니다!
이렇게 해커들이 사용하는 무차별 대입공격을 brute force라고 합니다
다시 JWT로 돌아와서
JWT의 특징으로는
중요한 내용을 저장하면 안된다는것입니다
그럼 이런생각도 들겠죠??
JWT를 쓰는 이유가 없지않는가?
하지만 JWT는 이 데이터가 조작이 됬는지 안됬는지를 알수 있기때문에
사용을 지속적으로 하고있습니다
그다음으로 볼것은
3.storage입니다!
크게 3가지가 있는데요!
localStorage,session storage cookies 가 있습니다!
이들의 차이점은
localstorage는 브라우져를 껏다가 켜도 남아있습니다
반대로
sessionstorage의 경우에는 브라우저를 끄는순간 데이터도 사라지게됩니다
마지막으로
cookies는 데이터에 토큰을 추가할수있습니다
가장 큰 차별점은 cookies는 백엔드와 통신을 할수있다는것입니다
다른 두개의 저장소는 브라우저에서만 사용을 하게 되고
쿠키의 경우에는 api요청시 같이 들어가게 됩니다!
그래서 백엔드에서도 쿠키에 어떤것을 넣어달라고 요청을 할 수도있게됩니다
즉 쿠키는
단순 저장소가 아니라
백엔드와 통신하기위한 저장소라고 생각하시면 될것같습니다!
오늘은 여러가지 방법으로 로그인을 어떻게 저장할지와 왜 이렇게 복잡하게 하는지
그리고 어떤방식으로 보안이 됬는지에 대해서 봤는데요!
로그인 겉으로 보기에는 별것 없는것 같았지만 참 복잡하죠?
오늘도 지식한개 저축쌓아가는 밸로그분들이 되셨으면 좋겠습니다!
그럼 오늘도 밸~바!
