AWS는 AgentCore Identity가 에이전트용 Private Key JWT 클라이언트 인증을 지원한다고 밝혔습니다.
원문은 RS256, PS256, ES256을 지원한다고 적고, 예시는 ECC_NIST_P256과 ES256입니다.
공개 키는 제공자에 등록하고, 비밀 키는 AWS KMS에 둔 채 토큰 요청을 서명할 수 있습니다.
AWS는 왜 클라이언트 비밀값 대신 서명된 JWT를 넣었나
AWS의 「Authenticate with Private Key JWT using Amazon Bedrock AgentCore Identity」는 AgentCore Identity의 새 지원을 알립니다. 원문은 에이전트가 다운스트림 아이덴티티 제공자의 토큰 엔드포인트에 서명된 JWT 클라이언트 어설션으로 인증한다고 설명합니다. 공유된 OAuth 2.0 클라이언트 비밀값 대신 서명 검증으로 신원을 확인하는 방식입니다.
AWS는 공개 키를 아이덴티티 제공자에 등록하고, 대응하는 비밀 키는 AWS KMS에 남길 수 있다고 밝힙니다. AgentCore Identity는 AWS KMS로 어설션에 서명하고, 제공자는 등록된 공개 키로 이를 검증합니다.
원문은 이 방식을 세 가지 흐름에 연결합니다.
- M2M은 에이전트가 자기 이름으로 동작하는 경우입니다.
- OBO는 사용자의 기존 토큰을 바탕으로 사용자 대신 호출하는 경우입니다.
- 사용자 위임 접근은 사용자가 먼저 동의하는 경우입니다.
서명 방식과 키 형식은 원문에서 이렇게 정해집니다
원문이 밝힌 값만 정리하면 다음과 같습니다.
| 항목 | 원문 값 | 무엇을 뜻하나 |
|---|---|---|
| 서명 호출 | kms:Sign |
AgentCore Identity가 KMS 비대칭 키로 JWT를 서명할 때 쓰는 호출입니다. |
| 서명 알고리즘 | RS256, PS256, ES256 |
제공자와 KMS, AgentCore Identity가 맞춰야 하는 서명 방식입니다. |
| 예시 키 스펙 | ECC_NIST_P256 |
예시에서 ES256과 함께 쓴 비대칭 키 스펙입니다. |
| OBO 대안 | RFC 8693 |
아이덴티티 제공자에 따라 쓸 수 있는 토큰 교환 규격입니다. |
| OBO 대안 | RFC 7523 |
아이덴티티 제공자에 따라 쓸 수 있는 JWT 권한 부여 규격입니다. |
| 공개 키 형식 | X.509 certificate, JSON Web Key |
공개 키를 등록할 때 제공자별로 맞춰야 할 형식입니다. |
| 생성 권한 | bedrock-agentcore-control:CreateOauth2CredentialProvider |
콘솔에서 자격 증명 제공자를 만들 때 필요한 권한입니다. |
"Convert the public key into the format your provider requires (for example, an X.509 certificate for Microsoft Entra ID or a JSON Web Key for Okta)"
기존 클라이언트 비밀값 방식과 갈리는 지점은 비밀값의 위치입니다
원문의 차이는 인증 재료를 공유하느냐가 아니라, 비밀 키를 어디에 두느냐에 있습니다. 공유된 클라이언트 비밀값은 없고, 공개 키만 등록합니다. 비밀 키는 AWS KMS에 남고, AgentCore Identity는 서명만 요청합니다.
On-behalf-of 흐름도 같은 원리로 동작합니다. 에이전트는 사용자의 기존 토큰을 입력으로 받아 downstream token으로 바꿉니다. 그 과정에서도 자기 자신은 client assertion으로 인증합니다.
원문은 아이덴티티 제공자에 따라 RFC 8693 token exchange 또는 RFC 7523 JWT authorization grant를 쓸 수 있다고 밝힙니다.
사용자 위임 접근은 조금 다릅니다. 여기서는 사전 토큰 교환이 없습니다. 사용자가 먼저 로그인하고 동의합니다.
그 뒤 authorization code grant로 사용자 권한을 반영한 토큰을 받습니다.
내일 점검할 항목은 KMS 키, 공개 키 형식, 제공자 권한입니다
가장 먼저 확인할 것은 서명 알고리즘의 일치입니다.
제공자, AWS KMS, AgentCore Identity가 같은 값을 써야 합니다.
원문은 RS256, PS256, ES256을 제시합니다.
그다음은 키 스펙입니다.
원문 예시는 ECC_NIST_P256과 ES256을 함께 사용합니다.
같은 조합이 아니라면 제공자 요구와 충돌할 수 있습니다.
그다음은 공개 키의 내보내기 형식입니다.
제공자가 무엇을 받는지 먼저 확인해야 합니다.
원문은 Microsoft Entra ID의 X.509 certificate와 Okta의 JSON Web Key를 예로 듭니다.
운영 측면에서는 권한도 점검해야 합니다. 원문은 KMS 키 생성과 공개 키 내보내기, 자격 증명 제공자 생성에 필요한 권한을 따로 적습니다. 또 CloudTrail 이벤트를 통해 에이전트 접근을 기록하고 확인합니다.
실무에서 바로 볼 체크리스트는 이렇습니다.
- 제공자가 Private Key JWT를 지원하는지 확인합니다.
- KMS 비대칭 키와 서명 알고리즘을 맞춥니다.
- 공개 키를 제공자 요구 형식으로 변환합니다.
- 비밀 키가 KMS 밖으로 나가지 않는지 확인합니다.
- CloudTrail로 인증 흐름을 남깁니다.
자주 묻는 질문
공개 키만 등록해도 왜 충분합니까?
충분합니다. 공개 키는 검증에만 쓰이고, 비밀 키는 AWS KMS에 남기 때문입니다. AgentCore Identity가 서명한 뒤 제공자는 공개 키로 진위를 확인합니다.
M2M과 OBO는 어떻게 다릅니까?
다릅니다. M2M은 에이전트 자신이 호출 주체이고, OBO는 사용자의 기존 토큰을 이어받습니다. 원문은 OBO에서 RFC 8693 token exchange 또는 RFC 7523 JWT authorization grant를 언급합니다.
Microsoft Entra ID와 Okta에서 공개 키 형식이 다른가요?
다를 수 있습니다. 원문은 Microsoft Entra ID의 X.509 certificate와 Okta의 JSON Web Key를 예로 듭니다.
따라서 공개 키를 내보내기 전에 제공자 요구 형식을 먼저 확인해야 합니다.
원문: 「Authenticate with Private Key JWT using Amazon Bedrock AgentCore Identity」