인증 Authentication

• 회원가입과 로그인을 말함
• 서비스를 누가 어떻게 사용하는지 추적이 가능하도록 하기 위해 필요함
• 아이디, 비밀번호, 이메일주소 필요. 특히 비밀번호 매우 중요!

- 암호화

단방향 해쉬

• MD5, SHA-1, SHA-256 등이 있음 (MD5, SHA-1 은 보안이 취약)
• 결과만 봐서는 당장 식별이 불가능하므로 완벽해보임
• 하지만 같은 알고리즘으로 '1234'를 다시 해싱하면 항상 같은 결과가 도출됨
• 이같은 허점을 보완하고자 salting 과 key stretching 이라는 것이 생김
  -> 비밀번호와 임의로 생성한 문자열을 해싱하여 이 해시값을 저장하는 방법

salting & key stretching

• 단순 해쉬값이 해킹에 쉽게 노출되기 때문에 salting 이라는 아이디어가 생겨남
• 입력한 비밀번호와 임의로 생성한 문자열을 합쳐서 해싱한 뒤 이 해쉬값을 저장하는 방법
• 물론 이때 비교를 위해 해쉬값과 소금(salt)값을 같이 저장해야 함
• 여기에 해커가 패스워드 무작위 대입을 통해 해쉬값을 계산하는데 필요한 시간을 대폭 늘리기 위해 salting 및 해싱을 여러번 반복해서 원본 값을 유추하기 어렵게 만드는 것이 key stretching.

bcrypt

• salting & key stretching 대표적 라이브러리
• 앞서 말한 개념들을 실제로 적용하기 편하게 해주는 대표적 라이브러리

---

인가 Authentication

• 사용자가 서버에 로그인 하면 해당 사용자가 맞는지 확인하는 과정

• http의 특징

1. req / res 요청과 응답
2. stateless한 성질 (저장하지 않는 성질)

• 위의 특징 때문에 서버는 사용자가 로그인 했을 경우에 로그인 했다는 것을 알 수 없음.
• 그럼 어떻게 알 수 있을까?
• 바로 header 에 메타데이터를 보내서 확인해야 함
• 이 메타정보를 바로 JSON Web Token 일명 JWT 라고 함.

JSON Web Token / JWT

헤더(header)

aaaa.bbbb.cccc
헤더 . 내용 . 서명

: 헤더에 들어가는 정보
1. 토큰의 타입과 해시 알고리즘 정보
2. 헤더의 내용은 BASE64 방식으로 인코딩해서 JWT의 가장 첫 부분에 기록 됨.

ex) { "alg":"HS256","typ":"JWT" }

내용(payload)

• exp와 같이 만료시간을 나타내는 공개 클레임
• 클라이언트와 서버간 협의하에 사용하는 비공개 클레임
• 위의 두가지 요소를 조합하여 작성한 뒤 BASE64 인코딩하여 두번째 요소로 위치
• 누구나 디코딩이 가능하기때문에 중요한 개인정보는 기입하지 않음.

ex) { "user-id:1, "exp":123242353 }

서명(signature)

• JWT가 원본 그대로 라는 것을 확인할 때 사용하는 부분
• BASE64URL 인코드된 header와 payload 그리고 JWT secret(별도생성)을 헤더에 지정된 암호 알고리즘으로 암호화 하여 전송함 (복호화 가능)
• 프론트엔드가 JWT를 백엔드 API 서버로 전송하면 서버에서는 전송받은 JWT의 서명부분을 복호화하여 서버에서 생성한 JWT가 맞는지 확인함
• 마치 계약서의 위변조를 막기위해 서로 사인하는 것과 같다고 보면 됨