마이크로 서비스를 통한 사용자 인증

12

마이크로 서비스가 자체 권한 부여를 처리해야합니까, 아니면 마이크로 서비스 전체 또는 일부 (동일한 비즈니스 도메인 내)에서 공유되는 별도의 인증 서비스를 사용하는 것이 더 낫다고 생각하십니까?

나에게 후자는 변경 사항을 적용하고 정책을 시행하기가 더 쉬워 지므로 더 의미가 있습니다. DRY 등입니다. 그러나 규칙을 한 곳으로 덤핑하는 모든 종류의 서비스로 인해 쉽게 벗어날 수 있으며 네트워크 오버 헤드에 대한 우려도 있습니다.

이견있는 사람?

architecture authorization microservices

— Morcmarc
소스

7

중앙 통합 인증 시스템을 사용하고 각 마이크로 서비스에 대해 별도의 권한 / 통계를 갖습니다 (이 스택 교환 사이트에서 아직 투표를 수행 할 수 없지만 중앙 스택 교환 인증 시스템을 사용하는 동안 스택 오버플로가 발생할 수 있음). 나의 현재 프로젝트 중 하나는 가까운 장래에이 접근법을 포함 할 것입니다. 이전 개발 작업에는 HIPPA 호환 시스템을 작성하여 2 단계의 인증 / 인증이 필요했으며, 법적으로 분리되었지만 기능적으로 분리 할 수없는 시스템 구성 요소에서 데이지 체인 인증을받는 데 시간이 많이 걸립니다. 디버깅 프로세스에는 간단한 oauth 로그인 또는 appid 및 x-auth 헤더가있는 api보다 훨씬 적은 기쁨이 포함됩니다.

사용할 로드맵은 개발 로드맵의 특정 요구 사항에 따라 다르지만 과도한 오버 헤드와 개발 시간 / 노력을 피하기 위해 가능한 간단한 방법을 선택합니다.

— 조나단 보스
소스

우리는 인증을 위해 OAuth2를 사용하며, 기능을 복제하고 서비스 전체에 로직을 분산시키는 것이 아니라 동일한 원칙, 즉 잘 정의 된 단일 책임을 가진 중앙 서비스를 갖는 권한을 부여하고 싶습니다. 나에게 그것은 도메인 경계를 위반하는 것입니다. 서비스 규칙 (ala stackoverflow, programmers)의 격리를 분류해야한다는 것을 동의하지만 동의합니다.

— morcmarc

2

소수의 핵심 마이크로 서비스가 동일한 권한을 사용하는 경우 유용한 서비스 별 권한으로 대체되는 전역 권한을 가질 수 있습니다. 중앙 인증 서비스의 잠재적 인 성능 문제를 피하려면 마이크로 서비스 별 권한이 해당 마이크로 서비스의 앱 인프라에 저장되어 있어야합니다.

— Jonathan Voss

4

각 마이크로 서비스는 자체 인증을 수행 할 필요는 없지만 자체 인증을 수행해야합니다.

출처

그리고 이것은 완벽하게 이해됩니다. 중앙 인증에 대해 의심의 여지가 없다고 가정합니다. 그러나 승인은 상당히 혼란 스럽다.

마이크로 서비스의 수가 최대 수십만 개까지 증가 할 수 있다는 점을 고려할 때 중앙 권한 서비스는 권한 만 나열해야하지만 해당 권한은 확인하지 않아야합니다. 개별 마이크로 서비스는 권한을 확인하기 위해 다르게 접근해야 할 수도 있습니다.

이 중앙 인증 서비스는 다른 서비스에서 모델을 가져와 결정을 위해 다르게 접근해야 할 수 있습니다. 처음에는 쉽고 예쁘게 보일 수 있습니다. 그러나 나중에 혼란 스러울 수 있습니다.

— 아쉬 와니 아가 왈
소스