23/11/08 TIL __ JWT 와 Token

 

 

jwt에 대해 궁금했는데 이번에 정리해 본다. 

 

 

🚗   JWT 

• 인터넷 표준으로 자리잡은 규격이다.
• JSON 형태의 데이터를 안전하게 교환해 사용할 수 있도록 하낟.
• header / payload / signature 형식으로 데이터를 가지고 있다( 개미 생각하면 기억하기 쉽다.)
• 따라서 JWT 형식으로 변환된 데이터는 항상 2개의 . 이 포함된 데이터야 한다.
• 쿠키에 jwt 토큰을 넣고, 쿠키와 함께 jwt 토큰을 전달하는 방식이다.
• 서버에 요청 후 클라이언트가 응답 받을때, 쿠키와 함께 JWT를 전달받는다.
• 이때 req 부분에 자동으로 쿠키를 할당하는 방법을 많이 사용한다.

 

 

 

⚽️  header   

• signature 에서 어떤 암호화를 사용해 생성된 데이터인지 표현한다.

 

⚾️  payload

• 개발자가 원하는 데이터를 저장한다.
• 세션의 키를 여기에 넣어두기도 하며,
• 유저를 확인하기 위해 유저 아이디에  대한 정보를 저장하기도 한다.

 

🏈   signature

• JWT 토큰 암호화를 했는지에 대한 데이터 저장한다.
• 언제까지 만료인지에 대한 데이터 저장한다.
• 변조되지 않은 정상 토큰인지 확인 할 수 있게 도와준다.
• 암호화 되어 있는 경우가 많다.

 

 

🚙  JWT 복호화

• 키가 없어도 페이로드 안에 어떤 데이터가 있는지 누구나 읽어볼 수 있다.
• 변조는 거의 불가능하다. 그러나 복호화 작업을 통해 누구나 볼 수 있다.
• 때문에 민감한 정보는 담지 않아야 한다.
• 쿠키와 세션은 데이터를 교환하고 관리하는 방식  /   JWT는 단순히 데이터를 표현하는 방식.
• 서버가 죽었다가 살아나도 똑같은 동작을 하는 Stateless  
• 서버에 데이터 저장 안한다는 말이다. 

 

 

🚌  Access Token 

• 리소스에 접근하기 위해 사용되는 토큰이다.
• 유효기간이 지나면 로그아웃 된다.
• 이 방식에서는 유효기간을 길게하면, 보안 문제가 생긴다.
• 토큰 기반 인증 방식이며  Stateless 이다. (서버에 데이터 저장 안한다는 말이다)
• 따라서 서버는 발급한 토큰에 대한 제어권이 없다.
• 토큰이 탈취된 경우, 컨트롤 할 방법이 없으며, 토큰 만료시까지 대기해야 한다.
• 사용자 권한 확인후 해당 사용자를 인증하는 용도.
• jwt 발급하고 설정한 expire 기간이 만료했을때 인증도 만료되게 하는것
•  access token 을 가지고 인증을 요청할 경우, token을 생성할 때  사용한 비밀키를 가지고 인증한다.
• 복잡한 설계 없이 코드 구현 가능 
•  jwt를 이용해서 사용자 인증여부는 확인이 가능 하지만, 처음 발급한 사용자 본인인지 확인할 수 없음.
• access token은 그 자체로도 사용자를 인증하는 모든 정보를 가지고 있다.

 

 

 

🚜  Refresh Token 

• access token의 유효기간을 짧게 설정하여 자주 재발급 한다. 
• 보안 강화 및 사용자의 로그인 지속을 도와 편의성을 높인다.
• 기존에 클라이언트가 가지고 있던  access token이 만료되면 새 access token을 받기 위해 refresh token을 사용한다.
• 사용자의 인증정보를 사용자가 가지고 있지 않고, 서버에서 별도의 db나 저장소에 보관, 관리한다.
• 토큰이 탈취된 경우, 그걸 만료시켜야 하는데, 서버에 따로 저장했던 토큰을 제거해 사용자 인증 여부를 언제든지 제어 가능하다. 
• 크게 JWT 형태와, 그것이 아닌 형태로 나눠서 볼 수 있다.

 

 

 

🚙  JWT 형태의 Refresh Token 

• access token과 똑같이 stateless 이다. (서버가 꺼졌다 켜져도 동일하게 동작)
• 토큰 자체에 데이터를 담는다.
• 유효성 검증 위해 데이터베이스에 따로 접근하지 않아도 된다.
• 서버 부하가 상대적으로 적다.
• 탈취당하면 서버에서 제어할 수 없다. 무효화 할 수가 없다

 

 

 

 

🚙  UUID 혹은  random string 형태의 Refresh Token

• 토큰이 사용자와 매핑되도록 데이터 베이스에 저장한다.
• 유효성 검증을 위해 데이터 베이스에 접근해야 한다.
• 탈취당하면, 그 즉시 무효화 할 수 있다.
• 단점으로는 사용자를 강제 로그아웃 하거나, 차단할 수 있다.

 

 

 

 

🚓  Refresh Token  의 한계

• access token 을 즉시 차단할 방법이 없다.
• 아무리 access token의 유효기간을 짧게 해도, 그 시간동안은 위험성이 존재한다.
• 해커에게 refresh token을 탈취당하면, 해커는 access token을 한번은 발행할 수 있다.
• 서버 db에  refresh token을 저장해서 직접 추적을 하면 조금이나마 피해 줄일 수는 있으나, 피해가 확인되고 나서야 조치가 실행된다.
• 그 전에는 토큰 탈취 여부를 알 수 없다.

 

 

 

참고한 블로그 

https://hudi.blog/refresh-token/