JWT에 role을 넣는 것은 과연 좋은 방법인가?

JWT를 언제 사용해야 하는가?

인가(Authorization): JWT의 가장 일반적인 사용 사례는 인가이다.

한 번 로그인이 성공하면, 이후의 모든 요청은 JWT를 포함하고 있어서 해당 사용자가 특정 API나 리소스에 접근할 수 있도록 해준다.

SSO(싱글 사인온): JWT를 많이 사용하는 이유 중 하나이다. JWT는 오버헤드가 작고, 도메인 간 사용이 쉬운 이점이 있다.

보안적 측면

보안적인 측면에서, JWT 안에 역할이나 권한 정보를 포함시킬지에 대해서는 신중히 다시 생각할 필요가 있다.한 번 토큰을 생성하고 서명하면, 그 토큰이 만료될 때까지 해당 권한이 부여된 상태로 유지된다. 그런데 실수로 admin 권한을 넣었을 경우, 그 사용자는 만료 시점까지 관리자 권한을 가지고 활동할 수 있게 된다. 어떤 사람들은 “토큰 수명이 짧으니 괜찮다”고 말하지만, 이건 강력한 논거가 아니다. 왜냐하면 짧은 시간 안에도 누군가는 큰 피해를 줄 수 있기 때문이다.

일부는 블랙리스트 DB를 운영해서 토큰 무효화 문제를 해결하려고 한다. 하지만 그렇게 되면 결국 JWT의 장점인 무상태(stateless) 아키텍처가 깨진다. 왜냐하면 매 요청마다 DB를 조회해서 블랙리스트에 있는지 확인해야 하니까, 이건 결국 세션 상태를 관리하는 방식이다.

그래서 더 나은 방식은, 사용자 권한 정보를 **인증 서버(DB나 Redis 등)**에 저장해두고, 요청이 들어올 때마다 서버에서 현재 역할(role)을 조회하는 것이다. 이렇게 하면 권한을 실시간으로 제어하거나 취소(revoke)할 수 있다. 참고로 JWT 표준에서 정의한 claims들은 대부분 **“누구인가?”**를 판별하는 인증(authentication)에 관한 것이고, “무엇을 할 수 있는가?” 라는 인가(authorization)에 대해서는 다루지 않는다.

결론

1. JWT에 역할을 포함하는 경우

• 편의성이 중요하고
• 권한을 가져오기 위해 DB 호출을 피하고 싶으며
• 사용자가 짧은 시간 동안 잘못된 권한을 가질 수 있는 가능성에 대해 개의치 않고
• 권한 정보를 추가함으로써 JWT 페이로드 크기가 조금 증가하는 것을 감수할 수 있을 때

2. JWT에 역할을 포함하고, 블랙리스트도 함께 사용하는 경우

• 사용자가 잘못된 권한을 가지는 시간 창을 없애고 싶고
• 이를 위해 매 요청마다 블랙리스트를 확인하는 비용을 감수할 수 있으며
• JWT 페이로드 크기가 약간 커지는 것을 감수할 수 있을 때

3. JWT에 역할을 포함하지 않고, 매 요청마다 권한을 조회하는 경우

• 잘못된 권한을 가진 상태를 방지하고 싶으며
• 블랙리스트 방식의 오버헤드를 피하고 싶고
• JWT 페이로드 크기를 최소화하고 싶으며
• 요청마다(또는 필요할 때마다) 권한을 조회하는 비용을 감수할 수 있을 때