2022_02_14

로그인

• 로그인 방식의 변화

  1. 로그인을 하면 인증기록을 Backend의 memory (Session) 에 기록함, 이후 특정 id 를 생성해 보내준다.

  2. 이 후 부터 특정 요청을 할 때는 Backend에서 부여해준 특정 id를 요청에 같이 보낸다.

  3. 사람들이 몰림에 따라 scale up(memory와 cpu 업글) 을 시켜주었다.

  4. 그대로 감당이 안되자 scale out(백엔드를 복제하여 서버 증축)을 하였다.

  5. 하지만 로그인 정보를 memory에 기록하기때문에(stateful) 각 서버마다 Session이 나뉘는 문제 발생

     ex) a 라는 브라우저에서 1번 서버에 요청하면 1번 session에는 기록되어 로그인으로 기록되지만 2번 3번에 요청하면 로그인 기록이 없기에 문제가 발생

  6. 로그인 기록을 session이 아닌 DB에 기록하는 방식(stateless)로 변경

  7. 변경하고나니 backend의 부하를 DB로 넘기는 꼴이 되었다.(초기방식과 다를게 없어짐)

  8. DB를 복제하려면 모든 데이터들이 같이 복제되야함으로 비용이 커지는 문제가 발생

  9. 하나의 테이블만 있었던 DB의 테이블을 나누는 방법을 찾게됨

     1. 수직 파티셔닝
     2. 수평 파티셔닝 = DB 샤딩

  10. 결과적으로 backend와 DB의 확장이 자유로워졌다. (Disk 저장 방식이다보니 DB를 긁는 문제가 발생)

      → 속도가 느림

  11. 추가적으로 Redis를 사용하여 DB메모리에 저장 → 속도 개선

  12. 로그인하면 Token을 DB Redis에 저장하고 유저에게 리턴, state, session, cookie, locakStorege등 에 저장하게 된다.

  13. 로그인 기록을 Backend에서 객체로 만들고(로그인 만료시간 포함) 그것을 암호화(Encoding) 그 암호를 토큰값으로 리턴해준다.

  14. 유저가 Token과 함께 요청을 하면 그 정보를 DB로 보내지 않고 바로 복호화(Decoding).

      이 때 주고받는 Token을 JWT(Json Web Token)이라 한다.

      → DB를 통하지 않아도 모든 백엔드에서 복호화가 가능하며 로그인기록을 알 수 있다.

  • 오늘날에는 크게 JWT 방식과 DB 샤딩, 2가지 방법을 이용한다.

• 로그인 Token이 외부에 유출 되었을 경우 타인이 해당값을 이용해 로그인을 할 수 있기때문에 Token에 만료기간을 지정한다.

• 백엔드에서는 Tokend을 발행할 때 해당 값을 묶는 key를 이용하여 서명처리 한다. (조작이 불가능하다.)

• 하지만 조회는 누구나 가능하기 때문에 Token에 중요한 내용은 기입하지 않는다.

• Permission

  여러개의 FE(사용자용, 관리자용, 사장용)중 어떤 것에 해당하는지 알려주는 것
  

• 암호화 2가지

  • 양뱡향 암호화: 암호화, 복호화 둘 다 가능
  • 단방향 암호화: 암호화 가능, 복호화 불가능 (Password Hashing)

• 로그인은 인증(Authentricaion) 과 인가(Authorization) 로 나뉘어진다.