- Login
- JWT
1. Login
로그인과 그 후의 흐름
1. 브라우저에서 이메일과 비밀번호를 입력하고 로그인 버튼 클릭
2. 백엔드로 데이터 전달
3. 벡엔드에서 DB로 전달 후 검증
3. 검증 결과를 백엔드에서 확인 후 메모리 세션에 로그인 상태와 함께 저장하면서 세션 ID 생성 ( 인증, Authentication )
4. 백엔드에서 세션 ID를 브라우저로 전달
5. 브라우저에서는 세션 ID를 저장하게 되는데, 이 저장 공간은 4가지 정도로 분류됨. 변수, localStroage, sesssionStorage, cookie
6. 브라우저에 저장된 세션 ID는 백엔드에 유저 관련 정보를 요청할 때 유저를 식별하는 용도로 사용됨. ( 인가, Authorization )
7. 식별 후 해당 유저에 대한 요청된 데이터를 DB로부터 가져와서 다시 브라우저로 전달
디스크와 메모리의 차이?
디스크는 컴퓨터의 파일 같이 영구적인 것들을 저장하는 곳
메모리는 변수 같은 휘발성인 것들을 저장하는 곳
인가(Authorization)가 필요한 기능들: 로그인, 결제
로그인 기능을 가진 사이트의 유저 수가 늘어나게 되면 세션도 점점 많아지고 그에 따라 메모리의 공간이 점점 부족해진다. 그 때 백엔드 컴퓨터에 메모리를 추가하거나(scale up) 백엔드 컴퓨터 수 자체를 증가시키는(scale out) 방법이 있다.
scale out에서 유저 수가 늘어나고 사용량이 많아지면 생기는 트래픽 분산 관리 알고리즘
1. least connection: 가장 접속이 적은 컴퓨터에 유저를 연결시키는 것
2. round robin: 유저가 접속할 때 마다 다음 컴퓨터로 연결시키는 것
문제점
메모리 세션은 stateful이기(상태를 가지고 있기) 때문에 접속하는 컴퓨터가 달라지면 로그인을 다시 해야한다.
해결책
stateful에서 stateless 전환하면 접속하는 컴퓨터가 다른 것이 문제가 되지 않는다. -> 백엔드가 아닌 DB(=디스크)로 저장하는 대안이 생김.
하나의 DB에 저장했을 때 병목현상이 발생한다.
병목현상이란 (bottle neck)?
물이 담겨있는 병이 있을 때 대개 병의 목 부분은 좁다. 병의 목 부분으로 한 번에 많은 양의 물이 나오려고 하면 물이 나오는 속도가 느려진다. 이와 같이 트래픽이 몰려서 느려지는 현상을 말한다.
병목현상 해결책
한 컴퓨터에 있는 DB의 테이블을 DB의 Partioning 기법을 사용해서 쪼갠 후 여러 컴퓨터의 DB에 담는다.
DB의 테이블을 나누는 기법
- 수직 파티셔닝
- 수평 파티셔닝(=샤딩)
세션이 stateless이기 때문에 어느 DB에 있는지만 알고 있으면 A컴퓨터에 접속을 할 때 B데이터베이스에 데이터가 있어도 세션 정보를 가져올 수 있다.
하지만, 인가(Authorization)를 할 때 마다 데이터베이스에 접근해야 하기 때문에 메모리보다 느릴 수 밖에 없다.
해결책
memcached, redis이라는 메모리 기반 데이터베이스에 저장하는 방법을 사용하면 메모리 기반이기 때문에 속도가 빠름. 대신 데이터가 휘발성으로 바뀜.
결국 DB까지 가야되긴 하잖아.. redis에 저장하지 않는 방법은 없을까?
-> 암호화를 사용하는 방법이 있다.
암호화란?
정말 기초적인 암호화를 하나 만들어보자면,
암호가 숫자로 이루어져 있을 때, 숫자를 알파벳으로 매핑시키는 알고리즘을 사용한다고 가정하자. 1 -> a, 2 -> b, 3 -> c 이런식으로.
이것을 복호화(매핑된 것을 다시 되돌리는 것)하는 방법은 나만 알고 있다.암호: 231458 ---암호화--- 암호화된 암호: bcadeh암호화에는 이렇게 복호화가 가능한 양방향 암호화가 있고, 복호화가 안되는 단방향 암호화가 있다.
인증 과정에서 해당 유저가 로그인 되어있다는 정보를 담은 객체 자체를 암호화 시키고 이 암호화한 것을 session ID로 대체시켜버리고 브라우저에 session ID로 넘겨주면, 인가 과정에서 브라우저는 session ID를 백엔드로 보냈을 때 백엔드에서 받은 session ID를 복호화시켜서 인가를 처리해버린다.
-> DB까지 갈 필요가 없어진다.
이 session ID를 JWT(JSON Web Token)이라 부른다.
현재 가장 많이 사용되는 방식은 redis에 저장하는 방식이고 암호화 방식이 가장 최신의 방식이다. JWT 만으로는 로그인을 완벽히 수행할 수 없다?
단방향 암호화(hash)는 왜 쓰는 걸까? 해킹 방지
요즘은 해킹 방지에 더 효과적인 단방향 암호화를 사용한다.
(비밀번호 찾기를 했을 때, 비밀번호를 알려주는 게 아닌 새로운 비밀번호를 입력하라고 하거나, 임시 비밀번호를 제공)
레인보우 테이블 -> 무차별 대입 공격 (brute force)
2. JWT
토큰 앞에 단어(예시: "Bearer" 또는 "Basic")를 붙여주는 것이 관례이다.
JWT 특징
JWT는 누구든지 열어볼 수 있기 때문에 중요한 내용은 저장되지 않는다.
대신 조작여부를 판별할 수 있다.
JWT는 길어질 수록 필드의 내용들도 추가가 되고 결국 크기도 커지므로 짧게 유지하는 것이 좋다.
Web Stroage
- Cookie
- Local Storage
- Session Storage
Cookie의 특징
- 쿠키는 항상 서버로 전송된다.
- 하나의 사이트에서 저장할 수 있는 최대 쿠키 수는 20개, 용량은 4KB이다.
- 쿠키는 만료 지점이 반드시 존재한다.
Local Storage의 특징
- 클라이언트에서 지우지 않는 이상 영구적인 데이터 보관이 가능하다.
- 도메인 마다 별도의 로컬 스토리지를 가진다.
Session Storage의 특징
- 클라이언트에서 지우지 않는 이상 영구적인 데이터 보관이 가능하지만, 브라우저를 닫으면 데이터가 소실된다.
- 도메인 마다 별도의 세션 스토리지를 가지며, 같은 도메인이더라도 브라우저가 다르면 별개의 스토리지가 된다.
로컬 스토리지와 세션 스토리지는 브라우저에서만 사용되는 저장 공간이고,
쿠키는 백엔드로 request를 날릴 때 항상 첨부된다.
Alogrithm
반복적인 패턴을 여러번 이어지면서 사용해야할 때는, 그 패턴의 길이를 늘려주기보다 % 를 사용해서 나머지를 구하는 방법으로 반복시킬 수 있다.
