인증은 무엇이고 왜 할까? (Authentication)
- 인증은 회원가입을 말한다.
- 인증은 왜 필요할까
-우리 서비스를 누가 쓰는지? 어떻게 사용하는지? 추적이 가능하도록 하기 위해 필요하다.
- 인증에 필요한 것은 무엇이 있을까?
-아이디, 이메일 주소, 비밀번호 등이 있다. - 비밀번호는 어떻게 관리해야할까?
-Database에 저장시 개인 정보를 해싱하여 복원할 수 없도록 한다.
-통신 시 개인 정보를 주고 받을때 SSL을 적용하여 암호화(HTTPS)
암호화는 어떻게 할까?
단방향 해쉬란?
- 본래 해쉬(hash)함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해서 쓰이지마느 복원이 불가능한 단방향 해쉬함수는 암호학적 용도로 사용한다.
- ex) MD5,SHA-1,SHA-256
- 결과만 봐서는 당장 식별이 불가능 하므로 완벽해 보인다.
- 하지만 같은 알고리즘으로 '1234'다시 해싱하면 항상 같은 결과가 도출된다.
SALTING & KeyStretching
- 단순 해쉬값이 해킹에 쉽게 노출되기 때문에 Salting이라는 아이디어가 생겼다.
- 입력한 비밀번호와 임의로 생성한 문자열을 합쳐서 해싱해서 이 해시값을 저장하는 방법이다.
- 물론 이때에 비교를 위해 해시값과 소금값을 같이 저장해야 한다.
Bcrypt
- 실제로 적용하기 편하게 해주는 대표적인 라이브러리
- 다양한 언어를 지원하고 있으며, 사용이 간편하여 쉽게 적용이 가능하다.
- bcrypt는 hash결과 값에 소금값과 해시값 및 반복횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB설계를 복잡하게 할 필요가 없다.
- bcrypt를 통해 해싱된 결과 값의 구조는 아래와 같다.
인가는 무엇일까? (Authorization)
- 사용자가 서버에 로그인하면 해당 사용자가 맞는지 확인하는 과정이 바로 인가이다.
- Http의 특징은 무엇일까?
-바로 request/ response 요청과 응답.
-stateless한 성질. - 서버는 사용자가 로그인 했을경우, 로그인 했다는 것을 어떻게 알 수 있을까?
-바로 header에 메타데이터를 보내서 확인한다. - 이 메타정보를 바로 JSON Web Token 일면 'JWT'라고 한다.
위의 그림은 JWT의 구조이다.
헤더에는 어떤 정보가 들어갈까?
- 토큰의 타입과 해시알고리즘 정보가 들어간다.
- 헤더의 내용은 BASE64 방식으로 인코딩해서 JWT의 가장 펏 부분에 기록된다.
다음은 내용(payload)이다
- 내용에는 exp 와 같이 만료시간을 나타내는 공개 클레임
- 그리고 클라이언트와 서버간 협의하에 사용하는 비공개 클레임
- 위의 두 가지 요소를 조합하여 작성한뒤 BASE64 인코딩하여 두번째 요소로 위치한다.
마지막은 서명(signature)이다
- JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분이다.
- 시그니쳐는 BASE64 URL인코드 된 header와 Payload 그리고 JWT secret을 헤더에 지정된 암호 알고리즘으로 암호화하여 전송한다.
- 프론트엔드가 JWT를 백엔드 API서버로 전송하면 서버에서는 전송받은 JWT의 서명부분을 복호화 하여 서버에서 생성한 JWT가 맞는지 확인한다.
- 마치 계약서의 위변조를 막기 위해 서로 사인하는 것과 같다고 보면 된다.
- 주의할 점은 header와 payload는 BASE64인코딩한 것이므로 누구나 원본을 볼 수 있으니 개인정보를 담아서는 안된다.
Frontend-Developer