JWT

🍟 인증과 인가 🍟

🍕 인증 Authentication 🍕

• 로그인 절차에서 정확한 이메일/비번 조합을 입력했는지 확인하는 과정
  ->결국 🥑 valid한 user인가? 🥑
• 인증은 왜 필요해? 우리 서비스를 누가 쓰는지? 어떻게 사용하는지 추적 가능하도록!
• 인증에 필요한 것? 아이디, 이메일주소, 비번(요게 가장 중요)
• 그럼 비번 어떻게 관리할건데? 🥑 암호화 🥑 시켜서!
• 그럼 암호화는 어떻게? db에 저장할 때 개인정보를 🥑 해싱 🥑 해서 복원할 수 없게!

• 비밀번호 암호화를 할 때 -> 단방향 해쉬를 씀!
• 단방향 해쉬? 🥑 복원이 불가능한 🥑 단방향 해쉬함수는 암호학적 용도로 사용. (해쉬테이블 ex. python 딕셔너리)
• 단방향 해쉬 단점?
  -> 가능한 경우의 수를 모두 해시값으로 만들어서 판매하는 서비스 존재 y
  해쉬값을 유추해주는 사이트도 존재.. 어휴
• 단순 해쉬값이 해킹에 쉽게 노출되니까 보완책이 필요해!
  -> 이걸 보완하고자 입력한 비번 + 문자열(salt) 합쳐서 해싱해서 이 해시값을 저장!
• salting & keystretching 말 그대로 소금치고 늘린다 그것도 여러번 !!!

🍕 Bcrypt 🍕

• Salting & KeyStretching 를 쉽게 해주는 대표적 라이브러리
  
• 다양한 언어 지원, 사용편해서 쉽게 적용 가능.

🍕 인가 Authorization 🍕

• 사용자가 서버에 요청 보내면 인증과정 거쳐서 🥑 확인된 사용자 🥑 가 맞는지 확인하는 과정.
  (이미 로긴 된 유저인지 확인하는 과정!)
• 잠깐! HTTP의 가장 중요한 특징?
  request / response 요청과 응답
  stateless한 성질(=저장하지 않는 성질)
• http는 stateless한데, 서버에서 요청을 받으면 사용자가 로그인한 상태인지 어떻게 알 수 있찌?
  -> 매 http요청마다 🥑 headers 🥑를 활용해 (authorization이라는 key에 담아!) 사용자가 🥑 인증절차를 거친 사용자 🥑 임을 증명하는 정보를 담아서 보내는 방법.

* 그렇다면 실제로 통신 어떻게 이루어지지?

(과거) + 지금도

		**client <--------------> server**

• 프론트에서 http로 요청이 들어오면 server가 메모리의 세션에 저장, id를 cookie의 형태로 담아서 보냄.
• client에서 브라우저에 쿠키를 저장
• 단점? -> client 하나, 서버가 여러개있으면 각자 메모리에 저장하기 때문에 서버끼리 공유가 안됨.
  -> 메모리를 다 따로 관리해주어야해.

🥑 그래서 json web token이라는 게 나타남.🥑

🥑 JWT (Json Web Token) 🥑

이메일/비번을 기입하여 인증된 사용자에게 발행해주는 제이슨 데이터 구조로 표현한 토큰
1. 수많은 프로그래밍 언어에서 지원됨.
2. 자가 수용적이다.(필요한 모든 정보를 자체적으로 지니고 있다. ex. 토큰 기본정보, 전달할 내용, 유저정보 등)
3. 두 객체 사이에서 쉽게 전달 될 수 있다. (ex. http 헤더에 넣어서 전달 가능, url 파라미터로 전달 가능)

(현재)

Json Web Token(JWT)

• 헤더(header): 토큰의 타입과 해시알고리즘 정보가 들어감
• 내용(payload): 만료시간을 나타내는 공개 데이터, 숨길필요가 없는 데이터(user-id 등)
• 서명(signature): jwt(string)가 원본 그대로라는 것을 확인할 때 사용하는 부분
  (=내가 첨보낼때 데이터랑 내가 나중에 받은 데이터랑 맞는지 확인하는 부분)
• 프론트엔드가 jwt를 백엔드 api서버로 전송하면 서버에서는 전송받은 jwt의 서명부분을 복호화하여 백엔드가 처음에 서버에서 생성한 jwt가 맞는지 확인

🍕 JWT를 활용한다면? 🍕

1. client가 서버에 http요청(로그인)하면,
2. 유저정보 확인 후 서버의 secret key(my_settings.py)를 활용해 jwt를 생성 및 jwt를 프론트에 보냄
3. 프론트에서 jwt를 브라우저(로컬 스토리지)에 저장하고
4. jwt를 포함한 http를 요청(헤더에 담아서!) 백에게~!
5. 백에서 jwt의 signature 부분을 확인 후, 해당 유저의 정보를 가져온다! 확인 후 유저의 정보가 일치하면!!
7. payload부분에 담아서 http 응답! 완료~!

* 그럼 아까의 단점 해결 어떻게?
-> 서버가 여러개. 각 해당 서버에서 똑같은 secret key를 공유하면됨 -> 그럼 계속 똑같은 값을 확인할 수 있는거니까!

🍆 JWT 장점?
JWT의 넓은 범용성, 무결성 보장, 필요한 값을 자체 포함할 수 있는 성질 때문에 많은 곳에서 JWT를 사용하고 있고, 앞으로 더 많은 곳에서 사용할 수 있을 것이다. 특히 MSA에서 서비스 간 통신 시 권한 서비스와의 의존성을 줄일 수 있어 서버와 서버 간 통신에 매우 유용하다.

🍆 JWT 단점?
단점으로는 사용자에 대한 권한이나 정보가 변경되는 경우 JWT를 새로 발급해야 하며, 경우에 따라 JWT의 크기가 커질 수 있다. JWT의 헤더나 페이로드는 디코딩(Decoding)하면 바로 내용을 확인할 수 있기 때문에 JWT의 모든 값들은 클라이언트에게 공개된다. 외부에 노출되어서는 안되거나 민감한 값이 노출될 수 있어 보안 문제로 이어질 수 있는 담점이 있다.

🍔 JWT 어렵당... 휴 🍔