알 수없는 소스에서 openid-connect 요청을 제한하는 방법.알 수없는 소스에서 openid-connect userinfo 요청을 제한하십시오.
액세스 토큰이있는 경우 누구든지 제한하고자하는 사용자 정보와 소유권을 userinfo에 저장하도록 요청할 수 있습니다.
은 알려진 클라이언트에서만 허용해야한다는 것을 의미합니다.
참고 : 우리가 신원 서버로 Keycloak를 사용하는
도와주세요!
먼저 액세스 토큰은 사용자 자격 증명과 동일하게 보호되어야합니다. OAuth2.0 프레임 워크는 동적으로 생성 된 토큰과 사용자 이름/비밀번호 기반 인증/권한 부여를 대체 할 수있는 기능을 제공합니다. 따라서 이러한 토큰은 보호되어야합니다. 그것이 TLS가 토큰 전송을위한 필수 요소 인 이유입니다.
RFC6749 section 10.3 - 액세스 토큰 자격 증명 (뿐만 아니라 기밀 액세스 토큰 속성) 인증 서버에서 공유 운송 및 저장 기밀로, 오직해야 리소스 서버에 액세스 토큰은 유효 액세스 토큰이 발급 된 클라이언트 액세스 토큰 은 [RFC2818]에 정의 된대로 서버 인증을 사용하는 섹션 1.6에 설명 된대로 TLS를 사용하여 전송해야합니다.
그렇다면 액세스 토큰의 오용에 대해 걱정할 경우 먼저 토큰 기반 통신 채택에 대해 걱정해야합니다. 고객은 토큰을 오용하지 않을 정도로 안전해야합니다.
다른 방법으로는 CORS 헤더를 사용하여 끝점에 대한 액세스를 제한 할 수 있습니다. 그러나 이것은 토큰을 보호 한 후에뿐입니다!
p.s 또는 네트워크 구성을 통해 알려진/유효한 IP 주소 만 백엔드와 통신 할 수 있도록 설정할 수 있습니다. 그러나 그것은 OIDC 프로토콜을 벗어났습니다.
감사합니다. 그러나 나는 실제 답변을 얻지 못했으며 예, 우리는 액세스 토큰을 보호하고 있습니다. 실제로, 알 수없는 출처 또는 우편 발송자를 통해 액세스 토큰을 가진 사용자라면 누구나 사용자 정보를 요청할 수 있습니다. 나는 이것을 제한하고 싶다. 요청이 고객 (Microservice)에서만 오는 경우 세부 정보를 공유하십시오. – Nick
@Nick 예를 들어 설명했듯이 올바른 액세스 토큰을 사용하여 우편 발송자 요청을 보내지 않습니까? 즉, 액세스 토큰이 보호되고 다른 당사자가 액세스 토큰을 얻을 수 없으면 userinfo 끝점에서 정보를 얻을 수 없습니다. 프로토콜의 보호는 액세스 토큰으로 제한됩니다 (내 대답은 이유를 설명합니다). 또는 네트워크를 조정하여 의도 된 대상이 아닌 다른 IP 주소를 블랙리스트에 넣을 수 있습니다. 그러나 그것은 네트워크 관점에서입니다. –