비밀번호를 DB에 저장하는 여러가지 방법이 있지만 그중 자주 쓰이는 bcrypt와 유저를 인증하고 식별하기위해 많이 쓰이는 JWT(JSON Web Token)에 대해 확실히 정리
: 최악 ㅎ
: 어떠한 암호를 이용해서 비밀번호를 암호화하고 그 암호를 이용하여 복호화도 가능
단점이라면 키가 노출되면 알고리즘은 대부분 오픈되어 있기 때문에 위험도가 높다.
: 해시로 암호화를 하며 복호화가 불가능
단점으로는 유저들은 비슷한 암호를 사용하기 때문에 레인보우 테이블을 만들어서 암호화된 비밀번호를 비교해서 비밀번호를 유추할수있다.
: 예를들어 A, B유저의 비밀번호가 똑같아도 salt값이 다르기 때문에 Hash값이 서로 완전 다르다. 이게 bcrypt 방식
: 당사자간에 정보를 JSON 개체로 안전하게 전송하기위한 컴팩트하고 독립적인 방식을 정의하는 개방형 표준!
로그인을 할때 로그인한 고유 유저를 위한 토큰을 생성해야 하는데 그 토큰을 생성할 때 JWT라는 모듈을 사용해야 한다.
간단하게 얘기하자마녀 정보를 안전하게 전할 때, 혹은 유저의 권한같은 것을 체크하기 위해 사용하는데 유용한 모듈
(이미지 출처: ://www.opennaru.com/opennaru-blog/jwt-json-web-token/)
: 타입, 해싱 알고리즘 SHA256, RSA등 토큰에 대한 메타데이터를 포함하고있다.
: 유저정보(issuer), 만료기간(expiration time), 주제(subject)등을 포함
⚠️ 페이로드에는 민감한정보를 담지 않게 주의❗️❗️
The very important thing to note here is that this token is signed by the HMACSHA256 algorithm, and the header and payload are Base64URL encoded, it is not encrypted. If I go to jwt.io, paste this token and select the HMACSHA256 algorithm, I could decode the token and read its contents. Therefore, it should go without saying that sensitive data, such as passwords, should never be stored in the payload.
https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide
: 토큰이 보낸사람에 의해 서명되었으며 어떤식으로든 변경되지 않았는지 확인하는데 사용되는 서명으로 헤더 및 페이로드 세그먼트, 서명 알고리즘, 비밀or공개키를 사용하여 생성
유저로그인 ➡️ 토큰 생성 ➡️ 토큰 보관
1. Admin만 볼수있는 글을 Admin/일반유저가 보고자 할때
2. 요청을 보낼때 보고나하고 있던 Token을 Header에 넣어서 같이 보낸다
3. 서버에서는 JWT를 이용해 Token을 다시 생성한 후 비교한다.
4. 비교해서 통과되면 볼수 있다.