jwt의 보안

1. jwt는 서버에 저장된 SecretKey를 알지 못하면 decode가 안된다 하였다.

근데 왜 탈취 당하는가? 

 

2. jwt 보안 강화

 

   2-1) Refresh token 사용

        1. 토큰 생성시 access token과 refresh token을 생성

           * access token의 유효기간은 짧게(ex_1시간), refresh token의 유효기간은 적당히(ex_2주)

        2. access token은 응답헤더에 실어보내고 refresh token은 디비에 해당 사용자의 데이터와 함께 저장 

        3. 서버에서 클라이언트의 요청을 받고 access token을 확인했을 때 해당 토큰이 만료되었다면 클라이언트단에   access token이 만료되었음을 알림

        4. 만료 통보를 받은 클라이언트 단에서 access token과 refresh token을 함께 서버로 보냄

        5. 서버는 클라이언트에게 받은 access token이 위조되었는지 확인(VERIFY SIGNATURE) 후 refresh token을 이용해 디비 조회(토큰 생성시 설정한 유효기간 확인)를 하고 새로 발급한 access token을 헤더에 실어 반환.

 

* refresh token은 access token을 새로 발급하는 기능 외에 다른 기능이 존재하지 않는다.

** 공격자가 header나 payload중 임의로 값 하나를 변환했다면 signature 부분이 바뀌어서 JWT 유효성 검사를 할때 통과를 못한다.

*** 엑세스 토큰이 만료가 되지 않았는데 리프레쉬토큰으로 재발급을 요청할 경우 토큰을 모두 만료시켜버린다
즉, 엑세스 토큰과 1:1 여부를 알기 위해 디비에 저장한다.

 

 

3. 장점&단점

 3-1 ) 장점 

• 기존의 Access Token만 있을 때보다 안전합니다.

 

 3-2) 단점

• 구현이 복잡합니다. 검증 프로세스가 길기 때문에 자연스레 구현하기 힘들어졌습니다(프론트엔드, 서버 모두)

• Access Token이 만료될 때마다 새롭게 발급하는 과정에서 생기는 HTTP 요청 횟수가 많습니다. 이는 서버의 자원 낭비로 귀결됩니다. 

 

 

  2-1) token의 저장위치 선정. Cookie vs LocalStorage

정리된 블로그 참조 : https://velog.io/@0307kwon/JWT%EB%8A%94-%EC%96%B4%EB%94%94%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C-localStorage-vs-cookie

 

 

부록 **암호화 알고리즘**

• 암호화 알고리즘의 종류

HS256

• HS256 는 HMAC SHA256 의 줄임말이다.
• 대칭키 방식 (공개키, 개인키)
  • 공개키로 암호화 한 암호문은 개인키로 풀 수 있는데 개인키는 절대로 밖에 오픈해서는 안되며 공개키로 개인키를 알아 낼 수 없어야 한다.

 

RS256

• RS256는 RSA + SHA256 의 줄임말이다.
• 공개키를 이용하는 대표적인 암호화방식인 RSA을 사용한것이다.

 

대칭키 vs 공개키(비대칭키)

 

1. 대칭키 암호화 방식

• 암호화/복호화에 사용되는 키가 같은 암호화 방식을 말한다.
• 장점 : 공개키 암호화 방식에 비해 속도가 빠르다
• 단점 : 키를 교환해야 한다(배송중 탈취 문제) / 사용자가 많아질수록 키가 많아짐

 

2. 공개키(비대칭키) 암호화 방식

암호화/복호화에 사용되는 키가 서로 다른 암호화 방식

 

참조 : https://liveyourit.tistory.com/183