Login
로그인시 BE Memory에 로그인 정보가 저장되며 이를 session라고 한다.
Br에서 BE로 요청이 많아지면 HW의 성능 업그레이드(scale-up: 수직 확장)만으로는 처리 속도에 한계가 있다.
많은 유저를 감당하기 위해서 스케일업뿐 아니라 BE 컴퓨터 자체를 복사해서 늘리는 방법을 사용한다. (Scale-out: 수평확장)
근데 스케일아웃을 통해 백엔드가 나뉜경우 세션은 어떻게 해야할까 ?
BE1번에 등록된 세션(로그인) 정보가 있는데(stateful) 인원 초과로 BE2에서 결제정보를 요청한다면 스케일아웃의 한계로 세션 정보까지는 복사하지 못하기 떄문에
애초에 로그인 정보등을 DB에 저장하기 시작했다.
DB에 저장하면서 스케일 아웃이 원활하게 가능해졌고 그 이유는 BE가 각자 가지고있던 정보(stateful)가 없어지고 DB에 저장하면서 (stateless) 정보를 공유할 수 있게 됐기 때문이다.
문제는 또 있다. 결국 stateless를 통해 DB에서 정보를 조회하게끔 하면 단순히 BE의 부하를 DB로 옮긴게 된다.
DB도 BE처럼 복사해서 여러대를 만들면 좋겠지만 복사를 하게되면 그만큼 금전적문제가 따르기도 하고 현실적으로 쉽지가 않다.
이를 보완하기 위해 나온게 테이블 파티셔닝이다.
파티셔닝은 수직, 수평(데이터베이스 샤딩) 방식으로 나뉜다.
JWT (JSON Web Token)
Br에서 최초 로그인-> BE에서 DB로 유저의 데이터 조회 -> DB에서 BE로 데이터 전송 -> 전송받은 데이터를 BE에서 객체형태로 저장 후 암호화
-> 해당 암호화된 정보를 유저에게 전달하고 결제 등 새로운 API를 사용시 유저가 가진 암호키를 BE에서 복호화
-> 복호화된 객체 데이터를 BE에서 검증 -> 검증 완료시 요청한 API 대로 진행
==> DB, 샤딩 등 없어도 로그인처리가 가능함
위의 과정에서 DB의 정보를 객체형태로 저장하고 저장된 객체를 문자열로 바꾸어 암호화해서 만들어진 키(토큰)를 JWT라고 한다.
JWT는 JWT.io라는 홈페이지에서 누구든지 조회는 가능하다
이러면 토큰을 탈취당하면 어떻게 하지? 라는 의문이 들 수 있지만 서명(비밀번호)를 통해 정보를 보호하고 있어 무결성을 보장한다.
그렇다해도 토큰이 가진 정보의 조회는 가능하므로 JWT에 중요한 정보를 담는것은 권하지 않는다.
Encrypt/Hash
암호화의 두 가지 방식.
예를들어 abcd -> 1234 이런 식으로 암, 복호화를 해주는 방식은 ‘양방향 암호화’라고 하며 abcd를 3827로 암호화를 하고 복호화가 안되게 하는 ‘단방향 암호화’ 방식이 있다.
양방향 암호화는 애초에 해킹의 위험때문에 비밀번호에 적용하지 않는다.
단방향 암호화는 다대일의 관계를 가지고 이런 방식을 Password Hashing 이라고 한다.
물론 이런 방식을 사용해도 마음먹는다면 매핑 테이블(레인보우 테이블)을 통해 무수히 많은 반복을 통해 비밀번호를 알아낼 수도 있다.
이렇게 로그인을 통해 토큰을 받아오는 과정을 ‘인증(authentication)’, 토큰을 가지고 API에 요청시 권한을 얻는 과정을 ‘인가(Authorization)’라고 한다.
