Manage end-user OAuth consent for AI agents with Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock AgentCore의 AgentCore Identity는 Consent portal을 통해 AI 에이전트의 사용자별 OAuth 동의와 세션 바인딩을 관리하고, GitHub·Slack 접근 토큰을 승인한 사용자와 연결해 보관한다.

📌 핵심 요약

• 기존에는 Authorization code grant를 사용하는 고객이 인증 URL 제공, 공개 HTTPS 콜백, 복귀 사용자 인증, 브라우저 세션 관리, CompleteResourceTokenAuth 호출을 직접 구현해야 했으나, Consent portal이 브라우저 리디렉션과 세션 바인딩을 관리한다.
• 사용자는 기업 IdP로 로그인한 뒤 GitHub와 Slack 등 각 제공자에 독립적으로 동의하며, AgentCore Identity는 발급된 토큰을 token vault에 저장해 이후 해당 사용자의 도구 호출에 사용할 수 있도록 한다.
• 구성에는 JWT inbound authorization을 사용하는 AgentCore Gateway, 포털이 검증할 수 있는 JWT 액세스 토큰을 발급하는 기업 IdP, 로그인용 OAuth2 자격 증명 제공자, GitHub·Slack용 별도 아웃바운드 제공자와 실행 역할이 필요하다.
• Consent portal은 게이트웨이당 1개만 생성할 수 있고 생성 후 게이트웨이를 변경할 수 없으며, openid 범위가 필수이고 Audience를 지정하면 게이트웨이에 구성된 값과 대조해 검증한다.
• 기업 IdP에는 <portal-url>/callback, 게이트웨이 대상의 기본 복귀 URL에는 <portal-url>/connect/callback, GitHub·Slack 애플리케이션에는 각 AgentCore Identity callbackUrl을 설정하며, 사용자는 동의 후 같은 게이트웨이에 연결된 IDE 또는 MCP 클라이언트로 돌아간다.

🧩 주요 포인트

1. 세션 바인딩의 관리형 제공 → OAuth 승인을 승인한 사용자와 연결하는 절차와 브라우저 처리의 자체 구현 부담을 줄인다.
2. 기업 IdP 로그인과 GitHub·Slack 동의의 분리 → 조직 사용자 인증을 유지하면서 서비스별 연결 여부와 접근 승인을 독립적으로 관리한다.
3. 게이트웨이당 1개 제약과 세 가지 콜백 경로 → 생성 전 게이트웨이를 확정하고 로그인·세션 바인딩·제공자 인증 코드 전달의 설정 위치를 구분해야 한다.

🧠 상세 정리

1. 사용자 동의와 세션 바인딩의 관리형 전환

AI 에이전트가 사용자를 대신해 GitHub나 Slack에 접근하려면, 사용자가 해당 제공자에서 인증하고 요청된 접근 권한을 명시적으로 승인해야 한다. 애플리케이션은 이때 얻은 OAuth 승인을 승인한 사용자와 안전하게 연결해야 하며, 원문은 이 과정을 세션 바인딩이라고 설명한다. 기존 AgentCore Identity의 Authorization code grant 사용자는 인증 URL 표시, 공개 HTTPS 콜백 호스팅, 복귀 사용자 인증과 브라우저 세션 관리를 직접 구현하고 CompleteResourceTokenAuth를 호출해야 했다. 새 Consent portal은 AgentCore Gateway를 위한 관리형 웹 경험과 세션 바인딩 엔드포인트를 제공한다. 포털이 브라우저 리디렉션과 세션 바인딩을 처리하면 AgentCore Identity가 결과 토큰을 token vault에 저장하므로, 고객이 직접 구축하던 동의 처리 흐름의 일부를 관리형 기능으로 옮길 수 있다.

2. Example Corp 개발 보조 에이전트의 사용 시나리오

원문은 Example Corp가 AgentCore Gateway를 통해 개발자에게 AI 코딩 보조 에이전트를 제공하는 상황을 예로 든다. 이 에이전트에는 저장소 목록 조회와 이슈 생성을 수행하는 GitHub 대상, 공개 채널 목록 조회와 메시지 게시를 수행하는 Slack 대상이 있다. 기업 IdP는 직원을 인증하고, 관리자는 각 OAuth 승인이 이를 승인한 직원과 계속 연결되도록 구성한다. 개발자는 두 제공자를 각각 연결할 수 있으며, 필요할 때 GitHub에 먼저 동의하고 Slack 접근은 별도로 승인할 수 있다. Kiro, Claude Code, Cursor, Visual Studio Code 같은 IDE 및 MCP 클라이언트에서는 도구 실행 전에 동의를 받아 두고 이후 호출에서 사용자에게 저장된 토큰을 활용할 수 있다는 점이 주요 사용 맥락이다.

3. 사전 준비와 관리자 권한의 범위

실습에는 Amazon Bedrock AgentCore에 접근할 수 있는 AWS 계정, JWT inbound authorization이 설정된 AgentCore Gateway, 그 게이트웨이에 연결된 IDE 또는 MCP 클라이언트가 필요하다. 기업 IdP의 관리 권한과 개발 또는 테스트 워크스페이스용 GitHub OAuth App 및 Slack app도 준비해야 하며, 각 제공자 애플리케이션에 AgentCore Identity 콜백 URL을 등록할 권한이 있어야 한다. 관리자는 IdP, 게이트웨이 대상, 실행 역할과 포털을 구성하는 1~6단계를 담당하고, 최종 사용자는 7단계에서 로그인과 제공자 연결을 수행한다. 제시된 관리자 IAM 정책은 포털과 OAuth2 자격 증명 제공자, 게이트웨이 및 대상의 관련 관리 작업과 실행 역할 생성·조회·정책 설정·전달 권한을 포함한다. 콘솔의 Create default role은 AmazonBedrockAgentCoreConsentPortalDefaultServiceRole-<suffix> 형식의 역할을 생성하며, 자체 역할을 사용한다면 iam:PassRole의 범위를 해당 역할 ARN으로 지정하도록 안내한다.

4. 기업 IdP와 포털 로그인용 자격 증명 구성

기업 IdP에는 Consent portal용 OIDC 웹 애플리케이션을 만들고 authorization code grant를 활성화한 뒤 client ID와 client secret을 생성한다. 로그인 범위에는 최소한 openid를 포함하고, 포털이 인증 엔드포인트·토큰 엔드포인트·서명 키를 확인할 OIDC discovery URL을 기록한다. 포털 URL이 아직 없으므로 임시 콜백 URL을 등록했다가 생성 후 실제 주소로 교체하며, IdP는 포털이 검증할 수 있는 JWT 액세스 토큰을 발급해야 한다. 원문은 Okta의 경우 애플리케이션과 해당 grant를 허용하는 접근 정책을 갖춘 사용자 지정 authorization server를, Auth0의 경우 필요에 따라 opaque token 대신 서명된 JWT를 받기 위한 audience 설정을 안내한다. 이후 AgentCore 콘솔의 Identity와 Outbound Auth에서 OAuth 클라이언트를 추가하고 기업 IdP의 자격 증명 및 OIDC discovery 구성을 입력하면, 포털이 로그인에 사용할 OAuth2 자격 증명 제공자가 마련된다.

5. GitHub·Slack 아웃바운드 연결의 준비

포털 로그인용 자격 증명 제공자와 별개로, GitHub 및 Slack에는 각각 아웃바운드 OAuth 자격 증명 제공자가 필요하다. 포털을 만들기 전에 두 OAuth 애플리케이션의 등록과 AWS Secrets Manager에 저장된 client secret을 확인하고, 각 자격 증명 제공자가 생성한 콜백 URL을 대응하는 애플리케이션에 등록해야 한다. 게이트웨이의 GitHub 및 Slack 대상은 authorization code grant를 사용하고 필요한 범위만 요청해야 하며, 상태는 Ready여야 한다. 포털 실행 역할에는 아웃바운드 자격 증명 제공자가 참조하는 고객 관리형 시크릿을 읽을 수 있는 권한이 필요하다. 이러한 구성은 기업 로그인과 서비스별 접근 승인을 구분하는 기반이며, 각 대상의 기본 복귀 URL은 포털 주소가 할당된 후 별도로 설정한다.

6. Consent portal 생성과 게이트웨이 연결 제약

관리자는 Identity 페이지의 Consent portals에서 포털을 생성하며, 이 목록은 해당 계정과 AWS 리전의 포털을 보여 준다. 이름은 문자·숫자·하이픈·밑줄을 사용한 1~50자로 지정하고 설명은 선택적으로 최대 512자까지 입력하며, 사용자에게 게이트웨이 이름이 표시되므로 알아보기 쉬운 이름을 선택한다. 게이트웨이당 Consent portal은 1개만 허용되고 생성 후 연결된 게이트웨이는 변경할 수 없으므로, 개발 보조 에이전트가 사용하는 게이트웨이를 정확히 선택해야 한다. 로그인용 IdP Credential Provider를 지정하고 필수 openid 범위를 유지하되 추가 범위는 필요할 때만 넣으며, Audience는 게이트웨이에 설정된 경우에 맞춰 지정하고 해당 값과 대조해 검증된다. 권한은 기본 역할 생성 또는 기존 역할 선택으로 구성하며, Creating 상태에서는 ARN과 실행 역할이 보이지만 URL은 아직 할당되지 않는다. 프로비저닝이 끝나 Active가 되면 https://<gateway-name>.consent-portal.bedrock-agentcore.<region>.amazonaws.com 형식의 URL과 포털 실행 버튼이 나타난다.

7. 서로 다른 세 가지 콜백 URL의 등록

포털이 생성되면 기업 IdP 애플리케이션의 임시 콜백을 <portal-url>/callback으로 교체하며, 주소 끝에 슬래시를 추가하지 않는다. 이 주소는 포털 로그인 후 사용자가 돌아오는 경로로, GitHub나 Slack 애플리케이션에 등록하는 콜백과는 역할이 다르다. Authorization code grant를 사용하는 각 게이트웨이 대상의 기본 복귀 URL은 <portal-url>/connect/callback으로 지정하며, 이는 사용자를 관리형 세션 바인딩 엔드포인트로 돌려보낸다. 아웃바운드 제공자 애플리케이션에는 OAuth 자격 증명 제공자를 만들 때 반환된 고유한 AgentCore Identity callbackUrl을 등록해, 제공자의 인증 코드가 AgentCore Identity로 전달되도록 한다. 관리자는 제공자 콜백과 게이트웨이 대상의 최종 구성을 확인하고 브라우저에서 포털 URL을 시험한 뒤, 승인된 커뮤니케이션 채널을 통해 개발팀에 주소를 전달한다.

8. 최종 사용자의 로그인과 독립적인 제공자 동의

개발자는 받은 포털 URL을 브라우저에서 열고 Sign in을 선택한 뒤 Example Corp의 기업 IdP에서 인증한다. 포털은 IAM 실행 역할을 사용해 게이트웨이에 구성된 대상과 연결 상태를 조회하고, 사용자는 Connections 페이지에서 GitHub와 Slack OAuth 클라이언트 및 대상 상태를 확인한다. GitHub의 Connect를 선택해 제공자 동의 페이지에서 요청 범위를 검토하고 승인한 뒤 돌아오면, GitHub는 Connected이고 Slack은 Not connected인 상태를 확인할 수 있다. Slack이 필요한 경우에는 별도로 연결을 시작해 워크스페이스를 선택하고 권한을 검토한 뒤 승인하며, 필요하지 않으면 연결하지 않은 상태로 둘 수 있다. 이후 사용자는 포털에 연결된 것과 동일한 AgentCore Gateway를 사용하는 IDE 또는 MCP 클라이언트로 돌아가며, 제공된 본문은 이 안내 도중 끝나므로 도입부에서 예고한 AWS CloudTrail 활동 검토의 실제 절차는 포함되어 있지 않다.

🧾 핵심 주장 / 시사점

• Consent portal의 핵심은 동의 화면 제공뿐 아니라, OAuth 승인을 승인한 사용자와 연결하는 세션 바인딩까지 관리한다는 데 있다.
• 기업 IdP 로그인과 서비스별 OAuth 동의를 구분하므로, 포털에 로그인한 상태에서도 GitHub와 Slack의 연결 여부는 서로 다를 수 있다.
• 관리형 포털을 사용해도 IdP의 JWT 발급, 실행 역할 권한, 제공자별 콜백 및 게이트웨이 복귀 URL을 맞추는 관리자 구성은 여전히 필요하다.

✅ 액션 아이템

• Consent portal 도입 대상의 JWT inbound authorization과 기업 IdP의 JWT 액세스 토큰 발급 구성을 확인한다.
• 게이트웨이당 1개 및 생성 후 게이트웨이 변경 불가 제약을 반영해 Consent portal에 연결할 게이트웨이를 확정한다.
• <portal-url>/callback, <portal-url>/connect/callback, AgentCore Identity callbackUrl의 설정 위치를 구분하고 GitHub·Slack의 독립적인 동의 흐름을 확인한다.

❓ 열린 질문

• 기업 IdP가 발급하는 JWT 액세스 토큰을 Consent portal이 검증할 수 있는가?
• 게이트웨이당 1개 및 생성 후 게이트웨이 변경 불가 제약을 고려할 때 어떤 AgentCore Gateway에 Consent portal을 연결할 것인가?
• GitHub와 Slack 중 사용자가 먼저 동의해야 하는 서비스는 무엇이며, 나머지 서비스의 접근 승인은 언제 필요한가?