JWT와 함께 Spring Boot 1.5.x + OAuth2를 사용하여 일련의 마이크로 서비스 (리소스 서버)를 개발했습니다. 현재 각 마이크로 서비스는 Spring Security를 사용하여 보호됩니다. 즉, JWT 액세스 토큰은 개별 리소스 서버 수준에서 확인됩니다. API Gateway에는 스프링 Security이 없기 때문에 요청을 적절한 서버로 라우팅하고 인증 헤더를 다운 스트림 서비스로 전파합니다.
AccessToken이 API 게이트웨이 수준에서만 확인되는 것과 비교하여이 설정의 단점이 있는지 알고 싶었습니다. 아니면 단지 의견의 문제입니까? API 게이트웨이 수준에서 Security을 유지하는 것은 느슨한 결합의 원칙을 깨뜨리지 않습니다. 각 마이크로 서비스가 자체 컨텍스트에서 지정된 사용자의 역할을 더 잘 이해할 수 있기 때문입니다.
API 관리는 JWT에 대한 작은 검사를 수행 할 수 있습니다 (초기 실패).하지만 마이크로 서비스는 모든 Security 항목을 실제로 관리 할 수있는 유일한 서비스입니다!
API 관리에만 Security을 설정하면 네트워크에 액세스 할 수있는 누군가가 인증되지 않은 API에 요청을 푸시 할 수 있음을 의미합니다. 누가 무엇을하는지 기록 할 수 없습니다. 마지막으로, 어떤 종류의 ACL을 설정해야하는 경우 불가능합니다 (주문 나열을 요청하면 주문 만 나열 할 수 있음).
아마도 API 관리 계층에서 JWT를 디코딩하고 위에서 언급 한 모든 것을 방지하기 위해 사용자 이름이 포함 된 헤더를 백엔드로 푸시하는 것을 생각할 것입니다.하지만 실제로는 좋은 방법이 아니라고 생각합니다.
첫째, 네트워크에 대한 액세스는 내가 누구든 될 수 있다는 것을 의미합니다. 그렇다면 JWT는 단순한 사용자 이름 그 이상입니다. 예를 들어 인증 계층에서 범위를 사용할 수 있습니다. (범위 읽기 순서 / 범위 수정 순서 / 범위 삭제 순서). 이는 애플리케이션이 할 수있는 작업 (client_id 수준에서) 또는 사용자가 애플리케이션에 제공하기 위해 수락하는 작업 (범위 공유 이메일 ...)을 제한하는 데 유용합니다. 백 오피스의이 JWT는 필수입니다.
좋아, 당신은 사용자 이름처럼 할 수 있고 API 관리에서 데이터를 추출하고 백엔드를 호출하기 위해 특정 헤더를 넣을 수 있습니다. 왜 특정한 일을합니까? JWT를 사용하는 oauth2가이 작업을 수행 할 수 있습니다.
| Java Base64 인코딩 및 디코딩 (0) | 2021.03.12 |
|---|---|
| 특정 스프링 빈을 나머지 엔드 포인트의 소비자에게 반환하면 어떻게 되나요? (0) | 2021.03.12 |
| JSON을 사용한 RestTemplate 포스트 요청 (3) | 2021.03.12 |
| Java를 사용하여 List에서 요소를 찾는 방법 (0) | 2021.03.11 |
| SpringData Jdbc를 사용하여 엔티티를 두 번 삽입 할 수없는 이유는 무엇입니까? (0) | 2021.03.11 |