Day 22) 1.로그인을 이해하려면 역사를 알아야돼! - Login 2. JWT토큰?? 이건 또 뭐야?! - JWT 3. 로그인 인증 토큰은 어디에 저장해?! - Recoil

송인호·2022년 6월 8일
1

dailyStudy

목록 보기
19/35

1교시 Login

1. 옛날 방식.

( 사용량이 적은 서비스에는 요즘도 많이 사용하고 있음 )

인증 - Authentication ( 인증 정보 가져오기 )

  1. 백엔드에 로그인 기능이 있고 브라우저에서 email/pw 를 넘긴다.

  2. 백엔드에서 DB에서 일치하는 이메일과 비밀번호가 있는지 확인하고
    있으면 그 유저가 로그인 했다 기록을 한다.( 백엔드 메모리 세션에 저장 )

  • 메모리: 램에 저장( 컴터 껐다 키면 사라짐 )
  • 디스크: 영구저장되는 저장소
  1. 세션 아이디를 브라우저에 돌려줌.

로그인하고 상품을 등록할 때

인가 - Authorization ( 로그인 검증을 받는 단계 )

  1. createProduct 에 price, name, description 등 아이디와 함께 넘겨준다.

  2. 백엔드에서는 메모리 세션과 비교하여 로그인 확인 과정을 거치고 상품 등록
    ( 없으면 에러메시지 )

요즘 방식 1.

백엔드 컴퓨터 분산

일을 하는것은 CPU
저장해두는 것은 메모리(램)

메모리를 초과하는 요청이 들어오게 되면 서버가 터진다.

해결방법:

  • 백엔드 메모리를 증가시키는 것 - scale up
  • 컴퓨터를 더 가지고와서 설치 - scale out

요즘은 scale out을 많이 한다.

백엔드 컴퓨터가 상태정보를 가지고 있다. 컴퓨터 마다 정보가 다르기 때문에 - satefull
statefull 상태에서는 scale out 하기 어렵다.

상태를 없애준다. - stateless
하나의 컴퓨터의 상태를 없애는데 DB(Session)에다가 저장을 한다.
그리고 scaleout을 한다.

예전의 memory에 있던 정보가 DB로 넘어오게 됐다.

DB의 분산

이렇게 되면 많은 정보들이 DB에 몰리게 된다.
DB의 과부화를 막기 위해 몇개를 더 만드는 것은 어렵다.
해결 방법: 나눠서 받는다.

User 테이블의 row를 나눈다 - 수직파티셔닝
User 테이블의 column을 나눈다 - 수평파티셔닝(= 샤딩 )

샤딩:

예를들어 1~100번은 1번 DB에 저장 101~ 200번은 2번DB에 저장
하는 식으로 DB를 분산시킬 수 있다.

DB는
속도가 떨어지다 보니깐 DB기반 메모리 Redis에 넣어 두어 부화를 분산한다.

요즘 방식 2.

토큰아이디만 가지고 저장을 안하고도 나머지 내용들을 알 수 있는 방식은 없을까?
예) 비밀번호를 암호화한다. 1234 -> abcd
복호화한다. abscd -> 1234

객체를 암호화 시킨다. JSON Web Token - JWT 토큰
복호화 할 수 있는 키만 가지고 있으면
이렇게 하면 DB가 필요가 없어진다.

2교시 JWT

인증

  1. email 과 pw를 입력하여 백엔드에 요청하면 login에 들어있는 객체정보를 암호화하여 브라우저에 던져 준다.

  2. 암호화된 JWT를 브라우저의 GlobalState에 저장을 한다.

인가

createProduct를 하려고 할 때 브라우저에서 JTW를 넘겨주고 백엔드에서는 암호화 된 것을 복호화하여 DB로 가서 상품을 등록한다.

인가에 집중을 해야한다.

accessToken 로그인인증 받을 때 전달해주는 토큰 ( JWT와 상관이 없고 JWT를 accessToken 으로 사용할 것이다.)

실습 PlayGround

JWT 토큰 키는 백엔드에 있지만 누구든지 열어볼 수 있다.

JWT IO

3600이 차이나는데 한시간마다 로그인을 해줘야한다. 그걸 막는 것은 refreshToken 이다.

누구든 열어볼 수 있지만 조작된 키인지 검증을 할 수 있다.
중요한 데이터는 넣으면 안된다.( 간단한 정보: ID와 만료시간 정도 )

state에 저장되고 인가가 필요한 Api 를 요청하는 방법을 알아 보겠다.

HTTP HEADERS 에 JWT를 넣어준다.
Bearer는 문자열이다. 토큰인증 관련해서는 Bearer를 쓰는것이 관례이다.
백엔드개발자분이 설정

네트워크창 여기에 들어가게 된다.

암호화

암호화에는 단방향 암호화와 양방향 암호화가 있다.

- 양방향 암호화 ( 암호화를 하고 복호화를 할 수 있었다 )
- 단뱡향 암호화 ( 암호화를 했는데 복호화를 못한다. -hash )

암호화가 되어있으면 해커에게 털려도 괜찮지만, 해커들은 암호화된 키의 알고리즘을 파악해 복호화하여 털린다.
그래서 단방향 암호화를 사용한다.

예를들어 2자리 수로 묶어 10을 나눈 나머지로 암호화를 하면 복호화 할 수 없다.
18, 28, 38 모두 8이 된다.

그래서 비밀번호 찾기를 했을 때 비밀번호가 나오지 않고, 다시 만들어야 한다.

하지만, 해커들은 hash에 있는 모든 경우의 수를 가지고 비밀번호를 알아낸다. ( 레인보우 테이블 )

최근에는 salt를 넣어서 경우의 수를 더 많이 만들어 준다.

3교시 Recoil

profile
프론트엔드 개발자

0개의 댓글