2017-03-21 5 views
18

지금까지 읽은 대부분의 튜토리얼은 @EnableResourceServer 대신 API 게이트웨이에서 @EnableOAuth2Sso을 사용합니다. 차이점은 무엇입니까? 대조적으로 OAuth2Sso의 기능은 무엇입니까?스프링 @EnableResourceServer 대 @ EnableOAuth2Sso

세부 사항 : 스프링 기반 마이크로 서비스 및 단일 페이지 응용 프로그램을위한 보안/인프라 아키텍처를 구현하고 있습니다. 얼마 동안은 보안 요구 사항이 없었지만 SPA는 다른 호스트 (CORS 파티)에서 열린 마이크로 서비스와 직접 대화했습니다.

이제 spring-oauthspring-zuul을 사용하여 보안 계층과 게이트웨이 패턴을 추가 할 예정입니다. 그래서 나는 @EnableAuthorizationServer의 서비스 (uaa-service)와 @EnableZuulProxy & @EnableResourceServer의 게이트웨이가 있습니다. 암호 그랜트 유형 만 있으면 각 SPA에 고유 한 로그인 양식이 있으며 uaa-service 토큰 끝점, 게이트웨이를 통해 인증 한 다음 추가 요청을 위해 해당 토큰을 계속 사용합니다.

이 방법에 문제가 있습니까? @EnableOAuth2Sso을 사용해야합니까?

+0

나는 누군가가 너에게 답을 주었으면 좋겠다. 나는 거의 같은 배에 타고있다. 최선을 다해서,'EnableOAuth2Sso' 주석은 이론적으로 "oauth aware"가 될 몇 가지 http 필터를 추가 할 것입니다. 예를 들어, 들어오는 요청에서 액세스 토큰을 자동으로 선택하고 백엔드 서비스로 전달한다는 아이디어가 있습니다. 하지만 실제로 작동하지 못했습니다. (사실 지금까지 주석은 제게 많은 것들을 부 셨습니다.하지만 지식이 부족하고 주석이 아님을 확신합니다!). – demaniak

답변

21

이 주석은 귀하의 서비스가 다른 OAuth 2.0 roles으로 표시됩니다.

@EnableResourceServer annotation은 OAuth 2.0 - Resource Server 측면에서 서비스가 요청을 처리하기 위해 액세스 토큰을 필요로한다는 것을 의미합니다. 액세스 토큰은 리소스 서버를 호출하기 전에 OAuth 2.0 클라이언트가 인증 서버에서 가져와야합니다.

@ EnableOAuth2Sso : 귀하의 서비스를 OAuth 2.0 클라이언트로 표시합니다. 즉, 자원 소유자 (최종 사용자)를 사용자가 자격 증명을 입력해야하는 권한 서버로 재 지정하는 책임이 있음을 의미합니다. 작업이 완료되면 사용자는 권한 부여 코드 (권한 코드와 혼동하지 마십시오)를 사용하여 클라이언트로 다시 리디렉션됩니다. 그런 다음 클라이언트는 권한 부여 코드를 가져와 권한 부여 서버를 호출하여 액세스 토큰을 교환합니다. 그 후에 만 ​​클라이언트는 액세스 토큰이있는 자원 서버를 호출 할 수 있습니다.

  • @EnableOAuth2Client : 당신이 @EnableOAuth2Sso 주석의 소스 코드에 대해 살펴 경우

    또한, 두 개의 흥미로운 일을 볼 수 있습니다. 여기서 서비스는 OAuth 2.0 클라이언트가됩니다. OAuth2RestTemplate을 통해 해당 서비스를 호출 할 경우 액세스 토큰 (인증 코드와 교환 된 후)을 다운 스트림 서비스로 전달할 수 있습니다.

  • @EnableConfigurationProperties(OAuth2SsoProperties.class). OAuth2SsoProperties에는 String loginPath이라는 속성 하나만 기본값 인 /login이 있습니다. 그러면 /login에 대한 브라우저 요청은 OAuth2ClientAuthenticationProcessingFilter으로 가로 채고 사용자를 권한 부여 서버로 리디렉션합니다.

@ EnableOAuth2Sso를 사용해야합니까?

그것은 따라 달라

  • 당신이 당신의 API 게이트웨이는 OAuth를 2로합니다.인증 코드 흐름 또는 리소스 소유자 암호 자격 증명 흐름을 사용하여 브라우저와 상호 작용하는 클라이언트 인 경우 대답은 '예'입니다. 나는 아마도 @EnableOAuth2Sso이 자원 소유자 패스워드 크리 덴셜 흐름을 잘 지원하는지 모르겠다 고 말했습니다. 어쨌든, 정말로 그렇게하지 않는 한, 권한 부여 코드 흐름으로 이동하는 것이 좋습니다. 그렇게하지 않는 것이 좋은 이유입니다. BTW, 인증 코드 플로를 사용하는 경우 다운 스트림 마이크로 서비스를 @EnableResourceServer으로 표시 할 수 있습니다. 그러면 API 게이트웨이는 OAuth 2.0 클라이언트가 될 것이고 마이크로 서비스는 나에게 논리적 인 OAuth 2.0 리소스 서버가 될 것입니다.
  • 는 브라우저와의 상호 작용이 필요하지 않은 경우 (예를 들어 클라이언트 자격 증명 흐름) 또는 당신이 유효한 액세스와 요청을 받아 들일 것을 의미, 흐름는 다음 사용한다 암시 @EnableResourceServer을 사용한다 SPA가 토큰 만 .
+4

oauth2에서 많은 마법적인 주석이나 클래스가하는 일을 의사가 찾을 수 없기 때문에 어떻게 그 모든 것을 파악 했습니까? – eugene

+5

그 대부분은 소스 코드를 조사하여 알아 냈습니다. 또한, 실험은 이러한 경우에 많은 도움이됩니다. :) –