2016-07-22 2 views
2

보안을 적용하려는 다중 마이크로 아키텍처가 있습니다.

내 보안 설계보기 : 인증은 LDAP에서 발생하며 사용자가 인증되면 "비밀 키"를 사용하여 JSON 웹 토큰 (JWT)이 생성되고 토큰에 역할이 있습니다. 만료 시간 등. 마이크로 서비스를 호출 할 때마다이 토큰이 헤더에 전달되어 권한 부여됩니다. 내 견해로는 사용자를 인증하고 JWT를 생성하는 하나의 인증 서버 만 있습니다.SpringCloud Microservices JSON Web Token (JWT) 보안

내 의심 : 전화 (헤더의 JWT를 포함)가 항상 인증 서버를 공격합니다 받게됩니다 microservice이 토큰이 이제
을 확인하려면?
그렇다면은 인증 서버를 여러 번 호출하므로 나쁜 방법이 될 수 있습니까?
이없는 경우 클라이언트는 토큰을 어떻게 확인하고 인증 서버의 범위는 무엇입니까?

답변

2

JWT는 항상 서명되어 있으므로 일부 중앙 인증 인스턴스를 호출하지 않고도 특정 토큰을 확인할 수 있습니다. 인증 서버는 토큰에 서명 할 비밀을 알고 있으며 토큰의 유효성을 검사하려는 모든 서비스에도이를 확인하는 방법이 필요합니다.

  • 대칭 : 비밀 값이 페이로드를 해싱 전에 추가됩니다

    은 서명하는 두 가지 방법이 있습니다. 소비 서비스는 또한이 비밀을 알아야하고 수신 된 페이로드에 비밀을 추가하고 전송 된 해시로 결과 해시를 검사하여 확인할 수 있습니다.

  • 비대칭 : 일부 PKI 서명/확인을 사용하면 인증 서버에만 토큰에 서명하는 개인 키가있을 수 있습니다. 모든 소모 서비스는 공개 부분 만 확인하면됩니다.

나는 두 번째 방법을 선호합니다. 키가 도난 당할 가능성을 줄입니다. 소비하는 서비스 중 하나가 도용 된 경우 공격자가 유효한 토큰을 만들 수 있도록 비밀이 분실되지 않습니다. 이러한 알고리즘을 사용하면 대칭 방식으로 사용되는 간단한 해시보다 유효성 검사에 더 많은 시간/cpu 사이클이 소요될 수 있습니다.

다른 메커니즘의 예를 들어 공식 JWT 페이지를 참조하십시오 :

+0

https://jwt.io/ 감사합니다,이 그것의 대부분에 응답합니다. 따라서 모든 마이크로 서비스에 공통된 공개 키가있는 경우 공개 키를 배포하는 가장 좋은 방법은 무엇입니까? DB를 통해 또는 마이크로 서비스의 경우 구성 서버를 통해? –

+0

이미 실행중인 구성 서버가 있고 PKI 버전을 사용하면이 방법으로 공개 키를 배포하는 데 문제가 없습니다. 이 통신은 반드시 안전해야합니다. 또 다른 방법은 일부 중앙 키 저장소에서 키를 가져 오는 것입니다. 이름을 나열하는 특수한 속성 인 'kid'가 있습니다. 자세한 내용은 jws 부록을 참조하십시오. https://tools.ietf.org/html/rfc7515#appendix-D –