Authenticate with Private Key JWT using Amazon Bedrock AgentCore Identity

🖼️ 인포그래픽

Authenticate with Private Key JWT using Amazon Bedrock AgentCore Identity 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock AgentCore Identity는 AWS KMS에 보관된 비대칭 개인 키로 단기 JWT 클라이언트 단언을 서명해, 공유 OAuth 클라이언트 비밀 없이 외부 자격 증명 공급자의 토큰을 발급받도록 지원한다.

📌 핵심 요약

AgentCore Identity는 자격 증명 공급자의 토큰 엔드포인트에 공유 클라이언트 비밀 대신 서명된 JWT 클라이언트 단언을 제출하며, 공급자는 사전에 등록된 공개 키로 서명을 검증한다.
개인 키는 AWS KMS 외부로 나오지 않고, AgentCore Identity가 구성된 RS256·PS256·ES256 알고리즘 중 하나로 kms:Sign을 호출해 단언에 필요한 서명을 생성한다.
지원되는 권한 부여 흐름은 에이전트 자체를 나타내는 기계 간 통신, 기존 사용자 토큰을 교환하는 대리 실행, 사용자가 대화형으로 동의하는 사용자 위임 접근의 세 가지다.
설정 과정은 호환되는 비대칭 KMS 키 생성, 공개 키의 자격 증명 공급자 등록, AgentCore Identity의 OAuth 클라이언트 생성, 검색 URL·클라이언트 ID·키 ARN·서명 알고리즘 입력 순으로 진행된다.
토큰 획득 과정은 CloudTrail의 GetWorkloadAccessToken, GetResourceOauth2Token, KMS Sign 이벤트로 기록되며, 반환된 토큰과 입력 토큰은 로그에서 보안상 숨김 처리된다.

🧩 주요 포인트

개인 키를 KMS 내부에 유지한 채 공개 키 검증 방식을 사용하므로, 외부 공급자 인증에 필요한 서명 작업과 키 보관 경계가 명확히 분리된다.
하나의 클라이언트 인증 방식이 기계 간 통신·사용자 토큰 교환·대화형 사용자 동의 흐름에 적용되므로, 호출 주체와 토큰이 나타내는 신원에 맞춰 권한 부여 방식을 선택할 수 있다.
KMS 키 정책과 동일 리전 조건, 알고리즘 호환성, 선택적 JWT 클레임, CloudTrail 기록을 함께 구성해야 실제 인증뿐 아니라 사용 경로의 통제와 감사도 가능하다.

🧠 상세 정리

1. 공유 비밀을 대체하는 개인 키 JWT 인증

AgentCore Identity의 개인 키 JWT 클라이언트 인증은 에이전트가 외부 자격 증명 공급자의 토큰 엔드포인트에 인증할 때 공유 OAuth 2.0 클라이언트 비밀 대신 서명된 JWT 클라이언트 단언을 사용하도록 한다. 자격 증명 공급자에는 검증용 공개 키를 등록하고, 그 공개 키와 짝을 이루는 개인 키는 AWS KMS에 보관한다. 인증 요청이 발생하면 AgentCore Identity가 KMS를 통해 단언에 서명하고, 자격 증명 공급자는 등록된 공개 키로 서명의 유효성을 확인한 뒤 접근 토큰을 반환한다. 글은 이 구조의 작동 방식뿐 아니라 지원되는 권한 부여 흐름, KMS 서명 키 생성, 공개 키 등록, 콘솔의 자격 증명 공급자 설정, CloudTrail 감사 이벤트까지 순서대로 설명한다.

2. 기계 간 토큰 요청의 전체 흐름

예시에서는 고객 지원 에이전트가 자격 증명 공급자로 보호된 내부 주문 API에서 고객의 주문 이력을 읽기 위해 AgentCore Identity의 GetResourceOauth2Token을 호출한다. AgentCore Identity는 자격 증명 공급자 설정에서 클라이언트 ID, KMS 키 ARN, 서명 알고리즘을 읽고 필수 페이로드 클레임과 구성된 선택적 헤더·페이로드 클레임을 포함한 수명이 짧은 JWT 단언을 만든다. 이어서 선택된 RS256·PS256·ES256 알고리즘에 맞춰 비대칭 KMS 키에 kms:Sign을 요청하며, KMS는 서명만 반환하므로 개인 키 자체는 KMS 외부로 나오지 않는다. 서명된 단언은 client_credentials 권한 부여 유형 및 JWT 전달자 단언 유형과 함께 자격 증명 공급자의 토큰 엔드포인트로 전송되고, 공급자가 공개 키로 서명을 검증하면 접근 토큰이 AgentCore Identity를 거쳐 에이전트에 전달된다. 에이전트는 그 토큰으로 주문 API를 호출하고, API는 검증된 요청에 대해 고객의 주문 이력을 반환한다.

3. 세 가지 권한 부여 흐름

기계 간 통신 흐름에서는 사람 사용자가 개입하지 않고 에이전트가 자신을 대표해 리소스에 접근하며, client_credentials 권한 부여를 사용하고 토큰의 주체도 클라이언트 자체가 된다. 이는 백그라운드 데이터 동기화나 호출한 사용자가 누구인지와 관계없이 고객 지원 에이전트가 읽을 수 있는 서비스 같은 경우에 해당한다. 대리 실행 흐름에서는 이미 로그인한 사용자의 기존 토큰을 입력으로 받아 하위 API용 토큰으로 교환하며, 에이전트는 클라이언트 단언으로 자신을 인증하면서 사용자의 신원과 권한이 이어지도록 한다. 이 흐름은 공급자 지원 방식에 따라 RFC 8693 토큰 교환 또는 RFC 7523 JWT 권한 부여를 사용할 수 있고, 사용자 위임 접근은 기존 토큰 없이 대화형 로그인·동의와 인증 코드 권한 부여를 거쳐 사용자를 나타내는 토큰을 얻는다는 점에서 구분된다.

4. 사전 준비와 필요한 권한

구성을 시작하려면 KMS, AgentCore, CloudTrail에 접근할 수 있는 AWS 계정과 관리 콘솔 권한이 필요하며, 애플리케이션용 공개 키를 등록할 수 있는 외부 자격 증명 공급자 테넌트도 준비되어야 한다. 클라이언트가 공급자 구성을 발견하고 연동할 수 있도록 검색 URL과 클라이언트 ID를 확보하고, 공급자가 요구하는 개인 키 JWT 서명 알고리즘을 먼저 확인해야 한다. 선택한 알고리즘과 키 사양은 AWS KMS와 AgentCore Identity 양쪽에서 모두 지원되어야 하므로 키 생성 전에 호환성을 맞춰야 한다. 권한 측면에서는 키 생성과 정책 구성을 위한 kms:CreateKey·kms:PutKeyPolicy, 공개 키 반출을 위한 kms:GetPublicKey, 자격 증명 공급자 생성을 위한 bedrock-agentcore-control:CreateOauth2CredentialProvider가 요구된다. 공급자가 생성한 키 쌍의 개인 키 재료를 KMS로 가져오는 방식이라면 kms:GetParametersForImport와 kms:ImportKeyMaterial 권한도 추가로 필요하다.

5. KMS 서명 키 생성과 공개 키 등록

KMS 키는 자격 증명 공급자와 같은 곳이 아니라 AgentCore의 자격 증명 공급자가 위치한 AWS 리전에 생성하며, 키 유형은 비대칭, 용도는 서명 및 검증으로 설정한다. 키 사양은 서명 알고리즘과 호환되어야 하며, 글의 예시는 ES256 알고리즘과 ECC_NIST_P256 키 사양을 사용한다. 키 정책에는 AgentCore Identity가 kms:Sign과 kms:DescribeKey를 수행할 수 있는 권한을 추가하고, kms:ViaService 조건으로 요청이 해당 리전의 AgentCore Identity 서비스를 통해 들어온 경우에만 키가 사용되도록 제한한다. 생성이 끝나면 키 ARN을 기록해 OAuth 자격 증명 공급자 설정에 사용하고, KMS에서 DER 인코딩 공개 키를 내려받아 공급자가 요구하는 형식으로 변환한다. 예를 들어 Microsoft Entra ID에는 X.509 인증서 형식이, Okta에는 JSON 웹 키 형식이 필요할 수 있으며, 변환한 공개 키를 해당 애플리케이션에 등록해야 한다.

6. AgentCore Identity의 OAuth 클라이언트 구성

관리 콘솔에서는 Amazon Bedrock AgentCore의 Identity 메뉴로 이동한 뒤 Outbound Auth 영역에서 새 OAuth 클라이언트를 추가한다. 공급자가 OpenID Connect 검색 엔드포인트를 제공하면 구성 유형으로 검색 URL을 선택해 AgentCore Identity가 구성을 자동으로 가져오도록 하고, 검색 엔드포인트가 없으면 수동 구성을 선택한다. 클라이언트 인증 방식에는 개인 키 JWT를 지정하고, .well-known/openid-configuration으로 끝나는 검색 URL과 공급자에 등록된 클라이언트 ID를 입력한다. 이어서 서명 및 검증 용도로 만들어진 비대칭 KMS 키 ARN과 공급자가 요구하는 서명 알고리즘을 선택하며, 키 사양과 알고리즘이 서로 호환되어야 한다. KMS 키는 기본적으로 자격 증명 공급자와 동일한 리전에 있어야 하고, 동일 리전의 다른 AWS 계정에 있는 키도 ARN을 직접 입력해 사용할 수 있지만 두 계정 모두에 추가 권한이 필요하다.

7. 선택적 JWT 클레임과 생성 검증

자격 증명 공급자가 표준 단언 외에 추가 정보를 요구하면 OAuth 클라이언트를 만들기 전에 선택적 헤더 클레임과 페이로드 클레임을 설정할 수 있다. 헤더에는 공급자별 키 식별자나 인증서 지문 같은 값을 추가할 수 있지만, 서명 처리에 사용되는 예약 키인 alg와 typ은 사용자가 설정할 수 없다. 페이로드에도 공급자별 요구 값을 넣을 수 있으나 iss, sub, jti, exp, iat, nbf는 AgentCore Identity가 관리하는 예약 키이므로 직접 지정할 수 없다. 필요한 클레임을 모두 추가한 뒤 OAuth 클라이언트를 생성하고, 생성된 자격 증명 공급자가 Outbound Auth 목록에 표시되는지 확인해야 한다. 이 구성에 따라 AgentCore Identity는 토큰 요청마다 필수 클레임과 허용된 추가 클레임을 결합해 수명이 짧은 JWT 클라이언트 단언을 만든다.

8. CloudTrail을 통한 접근 감사

에이전트가 구성된 자격 증명 공급자로 토큰을 가져오면 관련 작업이 CloudTrail에 기록되어 각 접근 과정을 감사할 수 있다. GetWorkloadAccessToken 이벤트에는 워크로드 이름과 워크로드 신원 리소스가 기록되며, 반환된 워크로드 접근 토큰은 HIDDEN_DUE_TO_SECURITY_REASONS로 숨김 처리된다. GetResourceOauth2Token 이벤트에서는 사용된 자격 증명 공급자 이름, 요청 범위, 기계 간 통신 같은 OAuth 2.0 흐름을 확인할 수 있고, 전달된 워크로드 신원 토큰 역시 로그에 노출되지 않는다. KMS의 Sign 이벤트는 AgentCore Identity가 JWT 클라이언트 단언을 서명하기 위해 실제로 kms:Sign을 호출했음을 보여 주며, userIdentity.invokedBy·sourceIPAddress·userAgent가 모두 bedrock-agentcore.amazonaws.com으로 나타난다. 따라서 토큰 값 자체를 로그에 남기지 않으면서도 어떤 워크로드가 어느 공급자와 범위 및 흐름으로 토큰을 요청했고 어떤 서비스가 KMS 서명을 수행했는지 확인할 수 있다.

🧾 핵심 주장 / 시사점

개인 키가 KMS를 벗어나지 않고 서명 결과만 AgentCore Identity에 반환되므로, 키 보관과 실제 OAuth 토큰 요청 처리가 분리된다.
세 권한 부여 흐름의 핵심 차이는 토큰이 에이전트 자체를 나타내는지, 기존 사용자를 이어받는지, 새 대화형 동의를 받은 사용자를 나타내는지에 있다.
KMS 키 사양·서명 알고리즘·자격 증명 공급자의 요구 사항이 모두 일치해야 하므로, 콘솔 설정 전에 세 구성 요소의 호환성을 확인하는 것이 필수다.