📌 Authentication
✏️ 인증이 필요한 이유
- 우리 서비스의 타깃 소비자를 분석하고 어떻게 사용하고 있는지 추적하기 위해
✏️ 인증에 필요한 항목
- ID, email, password(가장 중요)
✏️ 비밀번호 관리 방법
- Database에 저장 시 개인 정보를 해싱하여 복원할 수 없도록 함
- 통신 시 개인 정보를 주고 받을 때 SSL을 적용해 암호화(HTTPS)
- 배포하는 단계에서 암호화가 필요
📌 해싱이란?
암호가 스크램블된 표현으로 바뀌었음을 뜻함
📌 단방향 해쉬란?
-
본래 hash 함수는 자료구조에서 빠른 자료의 검색, 데이터 위변조 체크를 위해서 쓰이지만, 복원이 불가능한 단방향 해쉬함수는 암호화적 용도로 사용합니다.
-
MD5, SHA-1, SHA-256이 있습니다
-
'1234'를 SHA-256 해싱하면 특정한 값이 나오는데 다른 사람이 '1234'를 해시해도 같은 값이 나온다
-
이와 같은 허점을 이용해서 가능한 경우의 수를 모두 해시 값으로 만들어 판매하는 서비스도 존재한다
📌 Salting & Key Stretching
- 단순 해쉬값이 해킹에 쉽게 노출되기 때문에 salting이라는 아이디어가 생겼다
- 입력한 비밀번호와 임의로 생성한 문자열(salt)를 합쳐서 해싱해서 이 해시값을 저장하는 방법
- 물론 이 때 비교를 위해 해시 값과 소금(salt)값을 같이 저장해야 한다
- 여기에 해커가 패스워드 무작위 대입을 통해 해시값을 계산하는데 필요한 시간을 대폭 늘리기 위해 salting 및 해싱을 여러번 반복해서 원본 값을 유추하기 어렵게 만드는 것이 key stretching 이다
📌 bcrypt
- Salting & Key Stretching 대표 라이브러리
- 앞서 말한 개념들을 실제로 적용하기 편하게 해주는 대표적인 라이브러리
- 다양한 언어를 지원하고 있고 사용이 간편
- bcrypt는 hash 결과 값에 소금값과 해시값 및 반복 횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB 설계를 복잡하게 할 필요가 없습니다
- bcrypt를 통해 해싱된 결과 값(digest)의 구조는 아래와 같다
📌 Authorization 인가
- 해당 유저가 request에 해당하는 권한이 있는지 확인하는 절차
✏️ HTTP의 특징
- 바로 request/ response 요청과 응답
- stateless한 성질(저장하지 않는 성질)
✏️ 서버는 사용자가 로그인 했을 경우, 로그인 했다는 것을 어떻게 알 수 있나요?
- 바로 headers에 메타 데이터를 보내서 확인
- 이 메타정보를 'JSON WEB TOKEN (JWT)'라고 한다
- 요청 1의 응답 1에서 200 OK와 Token 발행
- 요청 2는 발행 받은 Token과 함께 요청 보냄
✏️ JSON Web Token
- 위 그림은 JWT 구조
- 헤더에는 토큰의 타입과 해시알고리즘 정보가 들어간다
- 헤더의 내용은 BASE64 방식으로 인코딩해서 JWT의 가장 첫 부분에 기록
- 예시 : {"alg": "
- 애초에 암호화를 하지 않는다. 암호화를 한다는 자체가 서버에서 부담이 되는 행위. 그래서 인가 과정에서 토큰을 보내주지 않는다. 애초에 개인 정보를 담지 않으면 암호화를 할 필요가 없다.
- 다음은 내용(payload)이다
- 만료 시간을 나타내는 exp와 같이 미리 정의된 집합인 Registered Claim
- 공개용 정보 전달을 목적으로 하는 public claim
- 클라이언트와 서버간 협의하에 사용하는 private claim
- 위의 세 가지 요소를 조합해 작성한 뒤 BASE64 인코딩해 두 번째 요소로 위치한다
- 예시 : {"user-id: 1, "exp": 1539517391 }
- 마지막은 서명(signature)이다
- JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분
- 시그니처는 BASE64URL 인코드된 header와 payload 그리고 JWT secret(별도생성)을 헤더에 지정 된 암호 알고리즘으로 암호화해 전송(복호화 가능)
- 프론트엔드가 JWT를 백엔드 API 서버로 전송하면 서버에서는 전송 받은 JWT의 서명 부분을 복호화해 서버에서 생성한 JWT가 맞는지 확인
- 마치 계약서의 위변조를 막기위해 서로 사인하는 것과 같다고 생각해보자
- 주의할 점은 header와 payload는 BASE64 인코딩한 것이므로(암호화아님) 누구나 원본을 볼 수 있으니 개인정보를 담으면 안된다
4대륙 개발자