OAuth 2.0 권한 부여 URL 세션 바인딩
AgentCore Identity는 에이전트 애플리케이션이 자격 증명 공급자/권한 부여 서버로 보호되는 타사 애플리케이션 공급업체 또는 리소스에 액세스할 수 있도록 OAuth 2.0 액세스 토큰 검색을 제공합니다. 애플리케이션 또는 리소스에서 사용자가 OAuth 권한 부여 코드 흐름으로 명시적으로 권한을 부여해야 하는 경우 AgentCore 자격 증명은 사용자가 액세스로 이동하여 동의할 수 있는 권한 부여 URL을 생성합니다. 그런 다음 사용자가 동의하면 AgentCore 자격 증명은 사용자를 대신하여 애플리케이션 또는 리소스에서 액세스 토큰을 가져와 AgentCore 자격 증명 토큰 볼트에 저장합니다.
그러나 사용자가 실수로 다른 사용자에게 권한 부여 URL을 보내고 해당 사용자의 애플리케이션 또는 리소스에 액세스할 수 있으므로 애플리케이션은 권한 부여 요청을 시작하는 사용자가 애플리케이션 또는 리소스에 대한 동의를 제공한 사용자와 여전히 동일한지 확인해야 합니다. 이렇게 하려면 사용자 확인을 처리하는 AgentCore Identity에 공개적으로 사용 가능한 HTTPS 애플리케이션 엔드포인트를 등록해야 합니다.
세션 바인딩 작동 방식
다음 흐름도와 해당 단계는 OAuth 2.0 권한 부여 URL 세션 바인딩 프로세스를 보여줍니다.
-
에이전트 호출 - 에이전트 코드는 원래 에이전트 사용자가 자신이 소유한 일부 애플리케이션 또는 리소스에 액세스하려는 경우
GetResourceOauth2TokenAPI를 호출하여 권한 부여 URL을 검색합니다. -
권한 부여 URL 생성 - AgentCore Identity는 사용자가 액세스로 이동하여 동의할 수 있는 권한 부여 URL 및 세션 URI를 생성합니다.
-
액세스 토큰 권한 부여 및 획득 - 사용자가 권한 부여 URL로 이동하여 에이전트가 리소스에 액세스할 수 있도록 동의를 부여합니다. 그런 다음 AgentCore 자격 증명은 권한 부여 요청의 원래 사용자가 포함된 정보와 함께 사용자의 브라우저를 HTTPS 애플리케이션 엔드포인트로 리디렉션합니다. 이 시점에서 HTTPS 애플리케이션 엔드포인트는 원래 에이전트 사용자가 애플리케이션의 현재 로그인한 사용자와 여전히 동일한지 확인합니다. 일치하는 경우 애플리케이션 엔드포인트는 AgentCore 자격 증명이 액세스 토큰을 가져오고 저장할 수
CompleteResourceTokenAuth있도록를 호출합니다. -
에이전트를 다시 호출하여 액세스 토큰 획득 - 애플리케이션이 유효한 응답을 반환하면 에이전트 애플리케이션은 원래 사용자에게 요청된 OAuth2.0 액세스 토큰을 검색할 수 있습니다. 사용자가 일치하지 않으면 애플리케이션이 아무 작업도 수행하지 않거나 시도를 기록합니다.
애플리케이션 엔드포인트가 사용자 자격 증명을 확인하도록 허용하는 AgentCore 자격 증명을 사용하면 에이전트 애플리케이션이 항상 권한 부여 요청을 시작한 사용자와 액세스에 동의한 사용자인지 확인할 수 있습니다.
구현 세부 정보
다음 단계에서는 에이전트 애플리케이션에 대한 OAuth 2.0 액세스 토큰을 검색하기 위해 리소스 공급자의 워크로드 자격 증명, OAuth 2.0 자격 증명 공급자 및 OAuth 2.0 애플리케이션 클라이언트를 설정하는 방법을 안내합니다.
샘플 코드를 실제 애플리케이션인 OAuth 2.0 콜백 서버 구현
중요
로컬 환경에서 agentcore dev와 함께 AgentCore CLI를 사용하는 경우 로컬 개발 및 테스트를 간소화하기 위해 CLI는 콜백 엔드포인트를 호스팅하고 사용자를 대신하여 CompleteResourceTokenAuth API를 호출하여 사용자 세션을 확인하여 OAuth 2.0 액세스 토큰을 가져오므로 다음 설정에서 1, 2 및 4단계를 건너뛸 수 있습니다. 그러나 에이전트 코드를 AgentCore 런타임에 배포할 때 에이전트 런타임에 연결하는 웹 애플리케이션은 공개적으로 액세스할 수 있는 HTTPS 콜백 엔드포인트 자체를 호스팅해야 하며, AgentCore 런타임에서 제공하는 에이전트 ID를 UpdateWorkloadIdentity 사용하여를 호출AllowedResourceOAuth2ReturnUrl하여 워크로드 자격 증명에 대해 콜백 엔드포인트를 로 등록한 다음 현재 사용자의 브라우저 세션을 확인한 후 CompleteResourceTokenAuth API를 호출하여 OAuth 2.0 권한 부여 흐름을 보호해야 합니다.
OAuth 2.0 권한 부여 URL 세션 바인딩을 구현하려면
-
애플리케이션 URL 생성 - 사용자 대면 브라우저 애플리케이션의 경우 사용자 브라우저에서 액세스할 수 있고 브라우저 리디렉션의 요청을 수락할 수 있는 새 URL을 생성하고 호스팅합니다. 이 페이지는 사용자가 에이전트 세션을 계속할 수 있는 애플리케이션 페이지로 리디렉션하거나 사용자에게 현재 활성 에이전트 세션을 반환하도록 지시하는 몇 가지 기본 웹 페이지를 렌더링해야 합니다. 구현의 후반부에서이 페이지는 현재 사용자의 활성 세션을 검증하는 데 사용되므로이 페이지는 애플리케이션 사용자 세션 데이터에 액세스하고 유지할 수도 있어야 합니다.
예를 들어 애플리케이션은 사용자가와 같은 기본 애플리케이션 페이지에서 에이전트와 상호 작용하도록
https://myagentapp.com/assistant할 수 있습니다. 이제가 기본 애플리케이션 페이지로 리디렉션https://myagentapp.com/callback할 것과 같은 새 URL을 노출하려고 합니다./callback엔드포인트의 실제 코드 로직은 나중에이 가이드를 따를 때 업데이트됩니다. -
애플리케이션 URL로 워크로드 자격 증명 업데이트 - ( AgentCore CLI를 통해 로컬에서 테스트하는 경우 건너뛸 수 있음) AgentCore 자격 증명이 리디렉션할 애플리케이션 URL을 생성하고 호스팅한 후에는 애플리케이션 URL이
AllowedResourceOauth2ReturnUrl로 등록되도록 워크로드 자격 증명을 업데이트합니다. 새 워크로드 자격 증명을 생성하는지 아니면 기존 워크로드 자격 증명을 업데이트하는지에UpdateWorkloadIdentity따라 사용된 IAM 자격 증명에CreateWorkloadIdentity또는를 호출할 수 있는 권한이 있는지 확인합니다.참고
AgentCore 런타임 또는 게이트웨이에서 사용자를 대신하여 생성한 워크로드 ID의 경우 워크로드 ID 이름은 서비스에서 발급한 런타임 ID 또는 게이트웨이 ID에 해당합니다.
샘플
UpdateWorkloadIdentityAPI 직접 호출:aws bedrock-agentcore-control update-workload-identity --name GoogleCalendarAgent \ --allowed-resource-oauth2-return-urls https://myagentapp.com/callback -
AgentCore 자격 증명에서 OAuth 2.0 자격 증명 공급자 생성 - OAuth 2.0 자격 증명 공급자를 완전히 등록하려면
CreateOauth2CredentialProvider및UpdateOauth2CredentialProvider를 호출할 권한이 필요합니다. 다음 단계를 따릅니다.-
클라이언트 ID 및 클라이언트 보안 암호에 대한 자리 표시자를
CreateOauth2CredentialProvider사용하여를 호출합니다. -
API 응답에는 다음과 같은 OAuth 콜백(리디렉션) URL이 포함됩니다.
https://bedrock-agentcore.amazonaws.com/identities/callback/123-456-7890생성된 각 공급자에 고유하며 나중에 OAuth 2.0 리소스 공급자에 필요하므로이 값을 기록합니다.
-
리소스 공급자(예: Google 또는 GitHub)로 이동하여 OAuth 2.0 애플리케이션 클라이언트를 생성합니다. 리소스 공급자에 대한
CreateOauth2CredentialProvider호출에서 서비스에서 발급한 콜백 URL을 허용된 OAuth 2.0 콜백 URL로 제공합니다. -
OAuth 2.0 애플리케이션 클라이언트가 생성되면 OAuth 2.0 자격 증명 공급자를 이러한 값으로 업데이트해야 하므로 앱 클라이언트에 할당된 클라이언트 ID와 클라이언트 암호를 기록합니다.
-
를 호출
UpdateOauth2CredentialProvider하고 리소스 공급자가 제공한 클라이언트 ID와 클라이언트 암호를 제공하여 자격 증명 공급자를 생성할 때 제공된 자리 표시자 값을 대체합니다.
-
-
CompleteResourceTokenAuth를 호출하기 위한 코드 핸들러 추가 - OAuth 2.0 자격 증명 공급자를 생성한 후 애플리케이션 URL 핸들러에서
CompleteResourceTokenAuthAPI를 호출할 코드와 IAM 권한을 추가합니다.CompleteResourceTokenAuthAPI를 호출할 때 애플리케이션은 OAuth 2.0 권한 부여 흐름과 관련된 사용자 및 에이전트 애플리케이션을 나타내기 위해 워크로드 액세스 토큰을 생성하는 데 사용된 원래 인바운드 자격 증명 공급자 OAuth 토큰 또는user_id문자열을 제공해야 합니다. 이 정보는 사용자 브라우저의 활성 애플리케이션 세션(일반적으로 브라우저 쿠키 또는 브라우저 로컬 스토리지를 통해)에서 가져와야 하며 원격 세션 캐시에서 가져와서는 안 됩니다.또한 AgentCore 자격 증명에서 생성되는 각 권한 부여 URL은 고유한 세션 URI로 고유하게 식별됩니다. 세션을 의도한 사용자와 바인딩하려면 사용자 식별자와 함께이 세션 URI도 표시해야 합니다.
중요
애플리케이션이
CompleteResourceTokenAuthAPI를 호출하기 전에 애플리케이션은 현재 사용자에게 애플리케이션과의 활성 상태의 유효한 세션이 있는지 확인해야 합니다. 이렇게 하면 애플리케이션이 의도한 사용자를 권한 부여 세션과 연결할 수 있습니다. 또한 애플리케이션이 의존하는 백엔드 서비스가 있는 경우CompleteResourceTokenAuthAPI를 호출하는 코드를 백엔드로 이동하고 애플리케이션이 인바운드 자격 증명 공급자 OAuth 토큰 또는 백엔드로 전달하도록user_id할 수 있습니다.샘플 애플리케이션 코드:
def _handle_3lo_callback(self, request: Request) -> JSONResponse: session_id = request.query_params.get("session_id") if not session_id: console.print("Missing session_id in OAuth2 3LO callback") return JSONResponse(status_code=400, content={"message": "missing session_id query parameter"}) session_details = validate_session_cookies(request.cookies.get('my-application-cookie')) user_id = None if oauth2_config: user_id = session_details.get(USER_ID) if not user_id: console.print(f"Missing {USER_ID} in session_details") return JSONResponse(status_code=500, content={"message": "Internal Server Error"}) console.print(f"Handling 3LO callback for workload_user_id={user_id} | session_id={session_id}", soft_wrap=True) region = agent_config.aws.region if not region: console.print("AWS Region not configured") return JSONResponse(status_code=500, content={"message": "Internal Server Error"}) identity_client = IdentityClient(region) identity_client.complete_resource_token_auth( session_uri=session_id, user_identifier=UserIdIdentifier(user_id=user_id) ) return JSONResponse(status_code=200, content={"message": "OAuth2 3LO flow completed successfully"}) -
테스트 - 설정을 완료하면 통합을 테스트할 준비가 된 것입니다. 먼저를 호출
GetResourceOauth2Token하고 브라우저에서 반환되는 권한 부여 URL로 이동합니다. OAuth 2.0 리소스 공급자에서 권한 부여를 완료하면 브라우저 리디렉션이 애플리케이션 URL로 다시 표시되고CompleteResourceTokenAuthAPI가 호출됩니다. 애플리케이션이 유효한 응답을 반환하면 에이전트 애플리케이션은 사용자에 대해 원래 요청된 OAuth 2.0 액세스 토큰을 검색할 수 있습니다. 이러한 토큰은GetResourceOauth2TokenAPI를 호출하여 가져올 수 있습니다.
추가 고려 사항
OAuth 2.0 권한 부여 URL 세션 바인딩을 구현할 때는 다음 사항을 고려해야 합니다.
-
각 권한 부여 URL과 해당 세션 식별자는 10분 동안만 유효합니다.
-
CSRF 공격으로부터 애플리케이션 콜백 엔드포인트를 보호하려면에 대한 API 호출에 포함할 불투명한 상태를 생성하는 것이 좋습니다
GetResourceOAuth2Token. 애플리케이션은이 값을 구문 분석하여 에이전트 애플리케이션에서 시작한 요청을 처리할 수 있어야 합니다.