TIL10 | 내가 보려고 올리는 - "인증과 인가"

인증 Authentication

• 인증은 왜 필요할까요 ?
  권한체크 보안확인 사용자를 식별하기 위해서
  -> 우리의 서비스를 누가 쓰며 어떻게 사용하고 있는지 추적이 가능하도록 하기 위해서

• 인증에 필요한 것은 무엇이 있을까요?
  id, Email, password 중 가장 중요한것은 password
  -> 비밀번호 어떻게 관리해야 하는가 : 법규상의 강제
  개인정보보호법 국가에서 권고하는 상용 암호화 알고리즘을 이용해 저장
  Database에 저장 시 개인 정보를 해싱하여 복원할 수 없도록 함
  통신 시 개인정보를 주고받을때 SSL을 적용하여 암호화(HTTPS)

• 암호화는 어떻게 할까요?

1. 해쉬 함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해서 쓰이지만 복원이 불가능한 단방향 해쉬함수는 암호화적 용도로 사용합니다
2. "1234"를 SHA=256 해싱하면 불라불라불라 하지만 같은 알고리즘으로 "1234"다시 해싱하면 항상 같은 결과가 도출
   -> 이와 같은 허점을 이용해서 가능한 경우의 수를 모두 해시값으로 만들어서 판매하는 서비스도 존재함 이것을 Rainbow Table 라고 부름
   이 허점을 보완하고자 "salting"과 "key stretching" 이라는 아이디어가 생겨났습니다 비밀번호로 임의로 생성한 문자열()

• salting key stretching

1. 단순해쉬값이 해킹에 쉽게 노출되기 떄문에 salting 이라는 아이디어가 생김
2. 입력한 비밀번호화 임의로 생성한 문자열(salt)를 합쳐서 해싱해서 이 해시값을 저장하는 방법입니다
3. 물론 이때에 비교를 위해 해시값과 소금값을 같이 저장해야합니다
4. 여기에 해커가 패스워드 무작위 대입을 통해 해시값을 계산하는데 필요한 시간을 대폭 늘리기위해 salting 밒 해싱을 여러번 반복해서 원본 값을 유추하기 어렵게 만드는것이 키 스트래칭 임돠
   
   
   

bcrypt 라이브러리

1. 앞서 나온 개념들을 실제로 적용하기 편하게 해주는 라이브러리
2. 다양한 언어를 지원하고 있으며 사용이 간편하여 쉽게 적용이 가능함니다
3. bcrypt 는 hash 의 결과값에 소금값과 해시값 및 반복횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 db 설계를 복잡하게 할 필요가 없습니다

인가 Authoruzation

• 해당 유저가 request 에 해당하는 권한이 있는지 확인하는 절차
• http 의 특징은 무엇일까요(바로 request/response 요청과 응답, stateless한 성질-저장하지 않는 성질)
• 인가는 무엇일까요?

1. 서버는 사용자가 로그인 했을경우, 로그인 했다는 것을 어떻게 알 수 있을까요
   바로 headers 에 매타데이터를 보내서 확인합니다
   이 메타정보를 바로 json web token 일명 "JWT" 라고 합니다

   aaaaaa(헤더).bbbbb(내용).ccccc(서명)

   위 예는 JWT의 구조입니다

• 해더 :

1. 토큰의 타입과 해시알고리즘 정보가 들어갑니다
2. 해더의 내용은 "" 인코딩해서 JWT의 가장 첫 부분에 기록됩니다

• 내용(payload) :

1. 만료시간을 나타내는 exp와 같이 미리 정의된 집합인 Requsterrd Claim
2. 공개용 정보 전달을 목적으로 하는 public Claim

• 서명(signature) :

1. JWT 가 원본 그대로라는 것을 확인할 때 사용하는 부분입니다.
2. 시그니쳐는 "" 인코드된 헤더와 내용 그리고 JWT 을 해더에 지정된 암호 알고리즘으로 암호화하여 전송합니다(복호화가능)
3. 프론트엔드가 JWT를 벡엔드 API 서버로 전송하면 서버에서는 전송받은 JWT의 서명부분을 복호화하여 서버에서 생성한 JWT가 맞는지 확인합니다.
4. 마치 계약서의 위변조를 막기위해 서로 사인하는 것과 같다고 보시면 됩니다.
5. 주의할 점음 헤더와 내용은 인코딩한 것이므로(암호화아님) 누구나 원본을 볼 수 있으니 개인정보를 담아서는 안됩니다.