2017-11-16 23 views
1

목표는 액세스 토큰을 통해 Resource Server (RS) resource.com/resource에 대한 액세스 권한을 부여하지만 OAuth2에서 사용 가능한 권한 부여 서버의 사용자 정의 인증 통합에 의존하는 대신 OpenId Connect를 사용하는 것입니다.OpenId Connect의 ID 토큰 피드를 다른 리소스에 대한 액세스 권한을 부여하기위한 후속 OAuth2 플로우에 어떻게 적용합니까?

어떻게 상호 운용되는지 명확하지 않지만, 아이디 토큰이 후속 OAuth2로 유입되는 방식은 무엇입니까?

1.OpenId Connect는 OAuth2 "사용자 프로필/ID에 대한 액세스 권한 부여"로 구현되지만 어떤 흐름을 사용합니까? 이 시점에서 요청자 (사용자 에이전트 또는 클라이언트 응용 프로그램)는 userInfo에 대한 id 토큰과 액세스 토큰을 가져옵니다.

2. 이제는 신원 확인, 엔드 서비스에 대한 권한 부여/액세스 토큰 (Resource Server RS)이 필요합니다. 리소스 서버에 대한 액세스 토큰의 최종 목표까지 다음 단계는 무엇입니까?

여기에 또 다른 OAuth2 흐름이 있으므로 사용자와 클라이언트의 신원에 따라 최종 액세스 토큰을 얻을 수 있습니다. 나는 이것에 대한 세부 사항을 가지고 있지 않다. 나는 OpenId의 상세한 프레젠테이션이 userInfo에 대한 id 토큰과 액세스 토큰을 가지고있는 지점까지 연결되어 있고 OAuth2의 자세한 표현은 모두 4 개로 이루어졌지만 이러한 프로토콜의 연결을 끝까지 보지 못했다는 것을 알았습니다. 그런 통합이 있습니까?

요청자가 코드 또는 액세스 토큰에 대한 요청과 함께 직접 (흐름에 따라) ID 토큰을 권한 서버로 보냅니 까? 끝 흐름과 끝 흐름을 결코 보지 못했습니다. 비디오 나 텍스트 설명을 나타낼 수 있습니까?

답변

1

일반적으로 클라이언트 응용 프로그램은 인증 토큰에 ID 토큰을 보내지 않습니다. (사양에는 id_token_hint이라는 요청 매개 변수가 있지만 혼동을 피하기 위해 무시해야합니다.)

일반적으로 리소스 서버에는 액세스 토큰 만 필요합니다. 클라이언트 응용 프로그램은 리소스 서버에 ID 토큰을 보낼 필요가 없습니다.

"Diagrams of All The OpenID Connect Flows"을 읽는 것이 도움이 될 수 있습니다.