search

DCBlock / Documentation

The DCBlock wiki
1 stars 0 forks source link

JWT 검증 알고리즘을 RSA를 적용하는게 어떨까요? #4

Closed sh0seo closed 5 years ago

sh0seo commented 5 years ago

현재 JWT 검증 방식을 AdminServer에 물어보는 방식을 사용하는데요(HMAC-SHA256). 이걸 RSA 알고리즘을 변경하는게 맞지 않을까 싶습니다. AdminServer에게 물어보는게 아니라 공개키를 다른 서버에게 미리 제공하는 방식으로...

JungByungOk commented 5 years ago

@devdotlog 지금 의견에 따라 생각해보니, RS256(RSA SIGNATURE WITH SHA256) 서명 방식을 사용하면 토큰 발급자의 개인키로 서명한 것을 참여한 모든 이해관계자들이 필요에 따라 토큰 발급자의 공개키로 서명 검증을 할수 있는 유연성이 있겠네요.

단지 서명에 대한 검증만 토큰 발급자에게 확인 받는것 뿐이라면 각자 검증하는것도 상관은 없다고 생각이되는데, 토큰 발급자에게 다른 무언가의 정보를 다시 받아야하는 경우가 있다면, 매번 토큰에 대한 상태를 확인하는 것도 필요할 것 같기도 하지만... 현재는 그러한 구현은 없기도하고요.

인증서버만 서명 검증 할 것이냐? VS 각자 개별 서버가 서명 검증 할 것이냐?

JungByungOk commented 5 years ago

인증서버만 서명 검증 할 것이냐? VS 각자 개별 서버가 서명 검증 할 것이냐?

토큰검증은 서명검증 외에도 클레임검증(scope, expiredin, expiredat 등등)등의 유효성 로직이 필요할것같습니다.

검증 공통모듈을 개별 api들이 직접 구현하고 있다고 생각해땐 개발/유지보수측면에서 인증 모듈의 일관성 유지라는 이슈도 발생하겠네요.

물론, 각자 검증을 하면 api호출을 한번 피하는 장점이 생기긴하는데, 토큰 검증api 구현을 안하는대신 jwt라이브러사용과 토큰 검증 구현이 필요하므로 구현측면에서도 비용효과적이지 않을것같습니다.

RS256을 적용하여 선택적으로 개별서버가 검증하고 추가로 admin api를 통해 검증하여 크로스체크를 하는것은 의미가 있을것 같습니다.

하지만, 개별로 각자 검증하는것은 개발/유지보수/ 측면에서 가성비 측면에서 효과적이지 않을것 같다는 의견입니다.

각자 보는 관점에 따라 장단점이 다를텐데요. 장점이 단점을 상쇄하고 단점을 수용할 범위인가에 따라 선택하면 좋을것 같습니다.

전적으로 저의 의견이므로 다른 관점에선 이런 효과가 있지않냐는 의견 주세요.

sh0seo commented 5 years ago

@bojung-dev 현재 상태를 유지하는 게 좋을 것 같습니다.

AdminServer가 없어도 토큰만 유효하다만 서비스에 문제 없는게 좋지 않을까라는 생각에 RSA256 알고리즘 변경 이슈를 공유했었습니다. 공개키만 있으면 각자 검증하고, 토큰은 갱신 주기를 짧게해서 처리하면 된다고 생각을 했었습니다.

다만, 유지보수 측면에서는 비효율적인건 동감합니다. 또한 현재 시점에서는 개발 시간이 더욱 중요하다고 생각됩니다.

그래서 현재 상태(SHA256)를 유지하는게 좋을 것 같습니다.