AWS bedrock-agentcore documentation change
Summary
Updated documentation with minor typographical changes (apostrophe formatting) and clarified that refresh token storage and usage is automatic in the section title.
Security assessment
The changes are primarily typographical (changing straight apostrophes to curly apostrophes) and a minor clarification in a section title. There is no indication of a security issue being addressed or a new security feature being documented. The existing content about OAuth2 flows, refresh tokens, and resource indicators remains the same in substance.
Diff
diff --git a/bedrock-agentcore/latest/devguide/identity-authentication.md b/bedrock-agentcore/latest/devguide/identity-authentication.md index 95cbbb349..b226c3821 100644 --- a//bedrock-agentcore/latest/devguide/identity-authentication.md +++ b//bedrock-agentcore/latest/devguide/identity-authentication.md @@ -5 +5 @@ -Refresh token storageStreaming authorization URLs to application callersResource indicators in AgentCore OAuth2 flows +Automatic refresh token storage and usageStreaming authorization URLs to application callersResource indicators in AgentCore OAuth2 flows @@ -72 +72 @@ Refresh tokens typically have longer lifespans than access tokens, with a defaul -This feature requires no configuration within AgentCore - it operates automatically when refresh tokens are present in the OAuth2 provider's token response. However, you must configure your OAuth2 provider to include refresh tokens in the authorization flow. The specific configuration depends on your provider: +This feature requires no configuration within AgentCore - it operates automatically when refresh tokens are present in the OAuth2 provider’s token response. However, you must configure your OAuth2 provider to include refresh tokens in the authorization flow. The specific configuration depends on your provider: @@ -99 +99 @@ Provider | Configuration Required -**Other providers** | Some providers require configuration in their provider settings rather than API parameters. Consult your provider's documentation for refresh token requirements. +**Other providers** | Some providers require configuration in their provider settings rather than API parameters. Consult your provider’s documentation for refresh token requirements. @@ -105 +105 @@ If your provider supports refresh tokens and is properly configured, AgentCore w -For three-legged OAuth (3LO) flows, your agent needs to provide the authorization URL to the calling application so users can complete the consent flow. While the examples above show printing the URL to the console, production applications require streaming the URL back to the caller through your application's response mechanism. +For three-legged OAuth (3LO) flows, your agent needs to provide the authorization URL to the calling application so users can complete the consent flow. While the examples above show printing the URL to the console, production applications require streaming the URL back to the caller through your application’s response mechanism. @@ -202 +199 @@ Choose the pattern that best fits your application architecture. Streaming respo -Resource indicators provide a standardized way to specify which resource server should accept an OAuth2 access token. AgentCore uses Cognito as its authentication provider, which supports RFC 8707-compliant resource indicators that allow you to specify the intended resource server during token requests. To use resource indicators, you must first configure the authorization server to recognize specific resource servers using Cognito's CreateResourceServer API. Once configured, when you specify a resource indicator in your token request, Cognito includes the corresponding resource server identifier in the aud claim of the resulting token, enabling the resource server to verify that the token is intended for its specific use. This provides several important benefits: resource servers can validate that tokens are specifically intended for them (principle of least privilege), improved auditability by clearly identifying which resource server each token targets, and reduced risk of token misuse across different services within your application environment. +Resource indicators provide a standardized way to specify which resource server should accept an OAuth2 access token. AgentCore uses Cognito as its authentication provider, which supports RFC 8707-compliant resource indicators that allow you to specify the intended resource server during token requests. To use resource indicators, you must first configure the authorization server to recognize specific resource servers using Cognito’s CreateResourceServer API. Once configured, when you specify a resource indicator in your token request, Cognito includes the corresponding resource server identifier in the aud claim of the resulting token, enabling the resource server to verify that the token is intended for its specific use. This provides several important benefits: resource servers can validate that tokens are specifically intended for them (principle of least privilege), improved auditability by clearly identifying which resource server each token targets, and reduced risk of token misuse across different services within your application environment. @@ -204 +201 @@ Resource indicators provide a standardized way to specify which resource server -Through Cognito's [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) implementation, AgentCore enables clients to specify a resource server directly in authorization and token requests, overriding the default audience parameter. In Cognito, the 'resource indicator' referred to in the RFC corresponds to the [ResourceServer's](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateResourceServer.html) 'identifier' value. Resource indicators are particularly important for Model Context Protocol (MCP) implementations, where they help mitigate specific security risks outlined in the MCP authorization specification. The resource indicator corresponds to the RFC 9728 resource parameter, ensuring proper token scoping for MCP server interactions. Note that the current implementation supports single-resource binding, meaning you can specify one resource server per token request. +Through Cognito’s [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) implementation, AgentCore enables clients to specify a resource server directly in authorization and token requests, overriding the default audience parameter. In Cognito, the 'resource indicator' referred to in the RFC corresponds to the [ResourceServer’s](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_CreateResourceServer.html) 'identifier' value. Resource indicators are particularly important for Model Context Protocol (MCP) implementations, where they help mitigate specific security risks outlined in the MCP authorization specification. The resource indicator corresponds to the RFC 9728 resource parameter, ensuring proper token scoping for MCP server interactions. Note that the current implementation supports single-resource binding, meaning you can specify one resource server per token request.