21.3.8

<인증 & 인가>

최대한 이해하고 사용하고, 면접 준비 때도 공부하기.

0. http의 여러 인증 방식

참고 링크

1. 인증?

• 로그인 절차에서 정확한 정보 확인("우리 유저인가?")
• 왜? : 서비스 사용자 추적
• 필요한 정보 : 아이디, 이메일, 비밀번호(암호화 하라고 "법규상" 정해져 있다.)

2. 비밀번호의 암호화

• 어떻게 관리해 ? : 데이터베이스 내에 해싱하여 복원할 수 없도록 함.
  

3. 단방향 해쉬함수, 레인보우 테이블 어택

1. 단방향 해쉬 : 해쉬함수(자료 구조에서 빠른 자료 검색, 데이터 위변조 체크, 복원 불가능한 단방향 해쉬함수는 암호학적 용도 사용) -> 투입을 시키면 랜덤하게 "뭔가를 변화시켜서 사용하는 것."(원래 값을 가져올 수 없음)

• 새로 비밀번호 받으면? 그 새로 받은 것도 해싱하면 똑같은 값 나와서 비교 가능; 비밀번호 까먹으면 왜 새로 만드는지 생각해보면 알 수 있음.(사용자도 데이터베이스도 서로 모르는 상황이 되어버림)
• 단방향 해쉬의 취약점 : 레인보우 테이블 어택

  미리 해쉬값 계산해놓은 테이블 ; 즉 공격자가 미리 만들어 놓은 해쉬 계산값을 대입해서 단방향 해쉬 패스워드를 해킹할 수 있다.

4. 설팅, 키스트레칭, bcrypt

<단방향 해쉬를 보완하기 위한 2가지 보완점>

설팅 & 해시
1. 설팅 : 해시 계산 할 때 소금(random한 문자열)을 쳐서 늘리듯 랜덤 데이터를 더해 놓기

(솔트값 알면???-> 또 걸리는데?)
그래서 사용하는 것이 키 스트레칭
2. 키 스트레칭 : 단방향 해시 후 그 해시를 또 해시하고 또 해시하고....(무한 반복, 원본값 유추 어렵게 해싱, 여러번 반복)

(이런거 다 해주는 라이브러리?)
3. bcrypt : 암호화(설팅 & 키 스트레칭) 라이브러리

• 소금값, 해시값, 반복횟수 같이 보관해준다.-> 알아서 해줘서 복잡할 것이 없다.
  

5. 인가?

• 쉽게 설명하면, 로그인 한 이후 상황을 예로 들 수 있는데.
  "장바구니 등을 이용자가 확인 할 때 확인 할 때마다 유저가 맞는지 확인하는 과정"
• 이미 로그인 된 이용자인데 왜 확인해? :

1. 요청 / 응답 / stateless를 이해하면 된다.
2. 각 요청과 응답은 stateless상태인데 이 때 요청 간 독립적인 상태를 이어주는 과정에서 "인증 받았어!" 라는 정보를 매 HTTP마다 HTTP headers를 활용하여 중간 중간 보내 줌.
3. 이 과정을 통해 사용자가 로그인 된 상태고, 그 사용자가 웹을 이용하고 있구나~ 라는 것을 허가해주는 상황을 만듦.
4. 여기서 headers안에 토큰 형태로 든 정보가 '메타정보'인데 이를 JSON Web Token, 일명 JWT라고 한다.

6. JWT?

<구조>

1. 헤더 : 가장 앞. 토큰의 타입, 해시의 알고리즘
2. 내용(payload) : 만료시간, 클라이언트-서버 간 사용하는 비공개 클레임을 인코딩해서 위치해 놓은 것

• 이 부분에는 사용자를 특정할 수 있는 정보가 들어가면 안 된다.

3. 서명 : 원본임을 확인하는 것.

• 서명에서 중요한 것 : 헤더 + 내용 + JWT secret를 조합해서 만듦. 서버에서 이걸 만들어서 줌. 이거 그대로가 아닌지 긴지 확인하는게 이 부분. 프론트가 이 부분 조금이라도 바꿔서 보내면 맞지 않음. 헤더가 지정한 해시 알고리즘으로 암호화해서 전송
• 프론트가 JWT를 백엔드 API서버로 보내면, 서버에서 전송 받은 JWT의 서명부분을 먼저 보는데 이 부분을 복호화해서 서버에서 생성한 JWT가 맞는지 확인.
  e.g. 계약서 이중 싸인

기존 인가와 다른 점 :

• 기존 인가 : 쿠키를 통해 전송. 단점으로 서버가 많아지면 서로 소통하기가 불가능(프론트에서 호출하고 싶은 서버가 많아질 때)
  

• JWT : SECRET_KEY 이용하여 서버마다 암호/복호화 공유할 수 있음

• 중요 사항 : 프론트가 백엔드에 토큰을 전달하는데 대체 어디에 넣어서 보내는가? :