JWT BestPractice

JWT 토큰 사용의 모범사례를 따라서 JWT 토큰 사용 시 JWT 토큰 사용이 단점을 최소화 하는 걸 목표로 해보겠습니다.

 

JWT 토큰의 구성

- 헤더(header)
- 페이로드(payload)
- 시그니쳐(signature)

1. 어떤 알고리즘을 사용해서 토큰을 생성할 것인가

- 대칭 알고리즘, 비대칭 알고리즘
- 대칭 알고리즘 HS256
- 비대칭 알고리즘 RS256, ES256
* HS란 HAMC-SHA

- HS256 : 32비트 컴퓨터
- HS512 : 64비트 컴퓨터

-> 여기서 RS256이 가장 권장되는 알고리즘 입니다.

2. 항상 토큰에 서명하기

적적한 알고리즘을 선택했다면 토큰 발행 시 항상 서명하는 것입니다.

JWT 서명은 토큰 내의 데이터(페이로드)가 변경되지 않았는지 확인하는 기본 보안 기능입니다.

3. JWT 토큰의 유효 수명 주기

따라서 JWT 수명을 최대 몇 초 또는 몇 분 단위로 최대한 짧게 설정해야 합니다. 그러나 절대로 며칠 또는 몇 달로 설정하지 마십시오.

 

4. 세션에 JWT 를 사용하지 마세요

 

5. 항상 발급사(iss) 확인

www.junseok.com 과 www.junseok.com/security 는 다르다

6. aud 확인

화이트리스트

7. 토큰이 의도한 대로 사용되었는지 확인

 

8. 토큰 만료시간

토큰 만료시간을 최대 몇분~몇시간으로 해야 함.

토큰이 한번 발행되면 취소되기 어려움

클레임 종류

- exp : 만료시간

- nbf : 이전시간

현재 시간이 nbf 클레임의 시간 이전이면 토큰 거부

- iat : 발행시간

리소스 서버에서 사용하기에 너무 오래된 것으로 간주되는 토큰 거부

 

만료 시간이 포함된 exp 클레임은 확인에 사용할 수 있는 유일한 시간 기반 클레임이 아닙니다. nbf 클레임에는 "이전" 시간이 포함되어 있습니다. 현재 시간이 nbf 클레임의 시간 이전이면 토큰을 거부해야 합니다. 또 다른 시간 기반 청구는 iat - 발행 시간입니다. 이 클레임을 사용하여 리소스 서버에서 사용하기에 너무 오래된 것으로 간주되는 토큰을 거부할 수 있습니다.

서버시간 오차에 대한 클럭스큐(clock skew) 허용 대신 30초 이상 사용하지 않는 것이 좋음

시간 기반 클레임으로 작업할 때 서버 시간은 시스템마다 약간 다를 수 있음을 기억하십시오. 시간 기반 값을 확인할 때 클럭 스큐를 허용하는 것을 고려해야 합니다. 이것은 몇 초의 값이어야 하며 일반적인 클럭 왜곡보다는 서버에 문제가 있음을 나타내기 때문에 이 용도로 30초 이상을 사용하지 않는 것이 좋습니다.

 

 

https://security.stackexchange.com/questions/119371/is-refreshing-an-expired-jwt-token-a-good-strategy

Is refreshing an expired JWT token a good strategy?

일반적으로 15분
accessToken 15분 - 401 받으면
refreshToken 보내줘야 함.
> 401에 refresh 토큰을 보내줬는지 확인가능? 그냥 refresh토큰 받은거 확인하면 되나
> 이러면 서버에 저장해 두었던 refresh 토큰과 비교? 아니면 이 때도 서버에 저장되지 않은 토큰 해석으로?

 

 

단점

토큰을 취소할 수 없음.

로그 아웃 시에 브라우저 캐시에서 토큰 삭제만 가능.

누군가 이 토큰을 가지고 만료기간 동안 계속해서 로그인 할 수 있음.

 

 

 

 

 

 

 

참고문서

https://blog.bitsrc.io/best-practices-for-using-jwt-df3788433fd3