AWS bedrock-agentcore documentation change
Summary
Updated JWT authorizer configuration documentation with API references, clarified validation logic for audiences/clients/scopes, restructured custom claims configuration with operator details
Security assessment
The changes enhance documentation about JWT validation mechanisms (audience/client/scope checks) and custom claim rules, which are security controls. However, there's no evidence of addressing a specific vulnerability - rather improving clarity of existing security features. The added 'at least one scope must match' requirement strengthens authorization checks but appears to be a documentation clarification rather than a vulnerability fix.
Diff
diff --git a/bedrock-agentcore/latest/devguide/inbound-jwt-authorizer.md b/bedrock-agentcore/latest/devguide/inbound-jwt-authorizer.md index 2e8a79712..9cb65a0ea 100644 --- a//bedrock-agentcore/latest/devguide/inbound-jwt-authorizer.md +++ b//bedrock-agentcore/latest/devguide/inbound-jwt-authorizer.md @@ -13 +13 @@ The inbound authorizer authenticates and authorizes incoming OAuth 2.0 API reque -You can configure your agent runtime or gateway to accept JWT bearer tokens by providing an authorizer configuration during agent creation. The authorization configuration is the same for either AgentCore Runtime or AgentCore Gateway. +You can configure your agent runtime (see [ CreateAgentRuntime](https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_CreateAgentRuntime.html)) or gateway (see [CreateGateway ](https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_CreateGateway.html)) to accept JWT bearer tokens by providing an authorizer configuration during agent or gateway creation. The authorization configuration (see [ CustomJWTAuthorizerConfiguration](https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_CustomJWTAuthorizerConfiguration.html)) is the same for either AgentCore Runtime or AgentCore Gateway. @@ -15 +15 @@ You can configure your agent runtime or gateway to accept JWT bearer tokens by p - * **Discovery URL** : A string that must match the pattern ` ^.+/\.well-known/openid-configuration$` for OpenID Connect (OIDC) discovery URLs. You can find your discovery URL from your identity provider. A discovery URL is a specific web address that AgentCore Identity can use to find information about the authentication endpoint details. It allows AgentCore Identity to dynamically configure itself to interact with your service without needing pre-programmed knowledge of its specific URLs. + * **Discovery URL** : A string that must match the pattern ` ^.+/\.well-known/openid-configuration$` for OpenID Connect (OIDC) discovery URLs. You can find your discovery URL from your identity provider. A discovery URL is a specific web address that AgentCore Identity can use to find information about the authentication endpoint details. It allows AgentCore Identity to dynamically accept tokens issued by your OIDC identity provider without explicit onboarding. @@ -17 +17 @@ You can configure your agent runtime or gateway to accept JWT bearer tokens by p - * **Allowed audiences** : A list of permitted audiences that will be validated against the `aud` claim in the JWT token. An audience claim (`aud`) in OAuth 2.0 specifies which resource server (API) the token is intended for. The resource server validates the `aud` claim to ensure it is the correct recipient before processing the request, preventing a token from being reused at a different API it was not issued for. + * **Allowed audiences** : A list of permitted audiences that AgentCore Identity will validate against the `aud` claim in the JWT token. An audience claim (`aud`) in OAuth 2.0 specifies which resource server (API) the token is intended for. The resource server validates the `aud` claim to ensure it is the correct recipient before processing the request, preventing a token from being reused at a different API it was not issued for. @@ -19 +19 @@ You can configure your agent runtime or gateway to accept JWT bearer tokens by p - * **Allowed clients** : A list of permitted client identifiers that will be validated against the `client_id` claim in the JWT token. A `client_id` in OAuth 2.0 is a public, unique identifier for an application that is requesting access to AgentCore Runtime or AgentCore Gateway. It acts like a username for the application, distinguishing it from other clients (applications) registered with the authorizer. + * **Allowed clients** : A list of permitted client identifiers that AgentCore Identity will validate against the `client_id` claim in the JWT token. A `client_id` in OAuth 2.0 is a public, unique identifier for an application that is requesting access tokens to access AgentCore Runtime or AgentCore Gateway. It acts like a username for the application, distinguishing it from other clients (applications) registered with the authorizer. @@ -21 +21 @@ You can configure your agent runtime or gateway to accept JWT bearer tokens by p - * **Allowed scopes** : A list of required permissions, defined as scopes, needed to invoke the runtime or gateway. An OAuth 2.0 scope is a string that defines a specific level of access that is defined in the JWT. Scopes act as permissions to limit what an application can do. + * **Allowed scopes** : A list of permitted permissions, defined as scopes, allowed to invoke the runtime or gateway. If configured, at least one scope value in the incoming token must match one of the configured values. An OAuth 2.0 scope is a string that defines a specific level of access that is defined in the JWT. Scopes act as permissions to limit what an application can do. @@ -23 +23 @@ You can configure your agent runtime or gateway to accept JWT bearer tokens by p - * **Required custom claims** : A set of rules to match specific claims in the incoming token against predefined values for validating JWT tokens. You can create a rule by specifying the following: + * **Required custom claims (see[ CustomClaimValidationType](https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_CustomClaimValidationType.html))**: A set of rules to match specific claims in the incoming token against predefined values for validating JWT tokens. You can create a rule by specifying the following: @@ -27 +27 @@ You can configure your agent runtime or gateway to accept JWT bearer tokens by p -**InboundTokenClaimValueType** : Either `STRING` or ` STRING_ARRAY`. + * **InboundTokenClaimValueType** : Either `STRING` or `STRING_ARRAY`. @@ -29 +29 @@ You can configure your agent runtime or gateway to accept JWT bearer tokens by p -**ClaimMatchOperator** : If ` InboundTokenClaimValueType` equals `STRING`, this can be `EQUALS` or `CONTAINS`. If ` InboundTokenClaimValueType` equals `STRING_ARRAY`, this must be `CONTAINS_ANY`. + * **AuthorizingClaimMatchValue** : Required value and comparison operator of the custom claim. @@ -31 +31 @@ You can configure your agent runtime or gateway to accept JWT bearer tokens by p -**AuthorizingClaimMatchValue** : Required value of the custom claim. + * **ClaimMatchValue** : Required value of the custom claim. @@ -33 +33,3 @@ You can configure your agent runtime or gateway to accept JWT bearer tokens by p -**Example** : You can define a rule that enforces: `Group must equal Developer`. + * **ClaimMatchOperator** : If ` InboundTokenClaimValueType` equals `STRING`, this must be `EQUALS`. If `InboundTokenClaimValueType` equals `STRING_ARRAY`, this can be `CONTAINS` or `CONTAINS_ANY`. + + * **Example** : You can define a rule that enforces: `Group must equal Developer`.