Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Authentification du client JWT par clé privée
Avec la clé privée JWT, AgentCore Identity s'authentifie auprès du point de terminaison du jeton d'un fournisseur d'identité en aval à l'aide d'une assertion de client JWT signée, conformément à la RFC 7523, section 2.2, au lieu d'un secret client. La clé privée ne quitte jamais le service de gestion des AWS clés (KMS). AgentCore Identity signe chaque assertion viakms:Sign. Votre fournisseur d'identité possède la clé publique correspondante utilisée pour authentifier l'assertion du client et renvoie un jeton d'accès.
Cette méthode élimine les secrets partagés entre AgentCore Identity et votre serveur d'autorisation, en les remplaçant par des paires de clés asymétriques sous votre contrôle total.
Comment fonctionne l'authentification du client JWT par clé privée
-
Vous configurez un fournisseur d'informations d'identification OAuth 2.0 personnalisé avec votre
clientId, l'ARN d'une clé de signature KMS asymétrique et le même algorithme de signature que celui requis par votre fournisseur d'identité pour l'authentification du client JWT par clé privée. -
Lorsque AgentCore Identity a besoin d'un jeton pour des flux de code de machine à machine (M2M), pour le compte (OBO) ou d'autorisation, elle crée une assertion client JWT de courte durée. L'assertion contient les déclarations requises par votre fournisseur d'identité.
-
AgentCore Identity signe ensuite l'assertion à l'aide de AWS KMS, avec la clé de signature asymétrique ARN fournie.
-
L'assertion signée est envoyée au point de terminaison du jeton comme c'est le
client_assertioncasclient_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer. -
Le serveur d'autorisation valide l'assertion par rapport à la clé publique que vous avez enregistrée et émet le jeton demandé.
La clé privée JWT est disponible sur le fournisseur d'informations d'identification OAuth 2.0 personnalisé (). CustomOauth2 Il fonctionne pour tous les flux d'autorisation : informations d'identification du client (M2M), échange de jetons avec autorisation JWT (OBO) et code d'autorisation (accès délégué par l'utilisateur).
Configuration de la clé privée JWT dans Identity AgentCore
Pour configurer correctement le fournisseur d'informations d'identification, vérifiez d'abord les exigences de votre fournisseur d'identité en matière d'authentification du client JWT par clé privée : algorithme de signature, clés publiques et déclarations d'assertion du client JWT requises.
Algorithme de signature
Identifiez l'algorithme de signature dont votre fournisseur d'identité a besoin pour l'authentification du client JWT par clé privée. Cela correspond au signingAlgorithm champ indiqué privateKeyJwtConfig lors de la création ou de la mise à jour d'un fournisseur d'informations d'identification personnalisé OAuth 2.0.
-
Spécifiez le même algorithme que l'algorithme de signature lorsque vous créez le fournisseur d'informations d'identification dans AgentCore Identity.
-
Cet algorithme de signature sera également utilisé pour choisir une spécification de clé KMS acceptable, détaillée ci-dessous.
AWS Configuration de clé asymétrique KMS
Déterminez comment votre fournisseur d'identité gère les clés de signature :
-
Si votre fournisseur d'identité accepte les clés publiques téléchargées, créez une paire de clés KMS asymétrique avec
SIGN_VERIFYutilisation. Choisissez une spécification clé qui prend en charge votre algorithme de signature (voir le tableau suivant). La clé doit se trouver dans la même région que le fournisseur d'informations d'identification. Spécifiez l'ARN de la clé KMS lors de la création du fournisseur d'informations d'identification sur AgentCore Identity.Après la création, utilisez l'GetPublicKey API kms : pour générer la clé publique correspondante.
kms:GetPublicKeyrenvoie une clé DER-encoded X.509 publique ou un SPKI. Certains fournisseurs d'identité ont besoin de ces clés publiques dans un format spécifique. Par exemple, Microsoft Entra nécessite un objet de X.509 certificat, Okta nécessite une clé Web JSON, tandis que Ping Identity prend en charge les deux. Convertissez la clé publique au format requis par votre fournisseur d'identité et téléchargez-la vers votre fournisseur d'identité. -
Si votre fournisseur d'identité crée la paire de clés et fournit le matériel de clé privée, importez-le dans une clé KMS avec
SIGN_VERIFYutilisation. Choisissez une spécification clé compatible avec l'algorithme de signature (voir le tableau suivant). Pour obtenir des instructions, consultez la section Importation de matériel clé pour les clés AWS KMS. Spécifiez l'ARN de la clé KMS lors de la création du fournisseur d'informations d'identification sur AgentCore Identity.
Ce que signingAlgorithm vous choisissez détermine quelles spécifications clés KMS sont acceptées :
| Algorithme de signature | Spécifications clés KMS acceptées |
|---|---|
|
|
|
|
|
|
|
|
|
AWS Politique de clé KMS
Pour utiliser une clé de signature KMS asymétrique pour la clé privée JWT, votre clé doit permettre à AgentCore Identity d'effectuer des opérations de signature et de description de clé en votre nom. Ajoutez les autorisations suivantes à la politique de clé de votre clé KMS.
Cette kms:ViaService condition garantit que la clé ne peut être utilisée que lorsque la demande provient d'Amazon Bedrock AgentCore Identity. Cross-account les clés sont prises en charge lorsque la politique de clé l'autorise kms:DescribeKey et kms:Sign à l'identité de l'appelant. Remplacez l'PrincipalARN par l'ARN racine du compte qui appellera AgentCore Identity.
{ "Id": "identity-service-cmk-policy", "Version": "2012-10-17", "Statement": [ { "Sid": "BedrockAgentCoreIdentityPrivateKeyJwtAccess", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": [ "kms:Sign", "kms:DescribeKey" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" }, "StringLike": { "kms:ViaService": "bedrock-agentcore-identity.*.amazonaws.com" } } } ] }
Cross-Region les clés ne sont pas prises en charge. La clé KMS doit se trouver dans la même AWS région que le fournisseur d'informations d'identification.
Réclamations supplémentaires dans JWT Client Assertion
Vérifiez si votre fournisseur d'identité nécessite des revendications supplémentaires dans l'en-tête d'assertion du client JWT ou dans la charge utile pour l'authentification du client JWT par clé privée. Si c'est le cas, incluez-les dans les additionalPayloadClaims champs additionalHeaderClaims etprivateKeyJwtConfig.
-
Car
additionalHeaderClaims, nous n'autorisons pas les réclamationsalgoutyp. -
En
additionalPayloadClaimseffet, nous n'autorisons pas les allégationsisssub,jti,exp,iat, ounbf. Nous autoriserons les annulations de laaudréclamation (par défaut, le point de terminaison du jeton de votre fournisseur d'identité).
Configuration du client OAuth avec un fournisseur personnalisé à l'aide de l'authentification JWT par clé privée
Pour configurer un fournisseur d'informations d'identification avec l'authentification du client JWT par clé privée, consultez la section Ajouter un client OAuth à l'aide d'un fournisseur personnalisé sur la AWS console. Vous pouvez également configurer le fournisseur d'informations d'identification à l'aide de l' AWS interface de ligne de commande.
Exemple de CLI : clé privée JWT pour un fournisseur d'informations d'identification Microsoft
aws bedrock-agentcore-control create-oauth2-credential-provider \ --cli-input-json '{ "name": "microsoft-private-key-jwt", "credentialProviderVendor": "CustomOauth2", "oauth2ProviderConfigInput": { "customOauth2ProviderConfig": { "oauthDiscovery": { "discoveryUrl": "https://login.microsoftonline.com/your-tenant-id/v2.0/.well-known/openid-configuration" }, "clientId": "your-client-id", "clientAuthenticationMethod": "PRIVATE_KEY_JWT", "privateKeyJwtConfig": { "privateKeySource": { "kmsKeySource": { "kmsKeyArn": "arn:aws:kms:us-east-1:111122223333:key/your-key-id" } }, "signingAlgorithm": "PS256", "additionalHeaderClaims": { "x5t#S256": "Base64url-encoded SHA-256 thumbprint of the DER encoding of the X.509 public key certificate uploaded to Microsoft Entra" }, "additionalPayloadClaims": { "aud": "https://login.microsoftonline.com/your-tenant-id/oauth2/v2.0/token" } } } } }'
Exemple de CLI : clé privée JWT pour un fournisseur d'informations d'identification Okta avec Token Exchange On-behalf-of
aws bedrock-agentcore-control create-oauth2-credential-provider \ --cli-input-json '{ "name": "okta-private-key-jwt", "credentialProviderVendor": "CustomOauth2", "oauth2ProviderConfigInput": { "customOauth2ProviderConfig": { "oauthDiscovery": { "discoveryUrl": "https://your-app.okta.com/oauth2/default/.well-known/openid-configuration" }, "clientId": "your-client-id", "clientAuthenticationMethod": "PRIVATE_KEY_JWT", "privateKeyJwtConfig": { "privateKeySource": { "kmsKeySource": { "kmsKeyArn": "arn:aws:kms:us-east-1:111122223333:key/your-key-id" } }, "signingAlgorithm": "RS256" }, "onBehalfOfTokenExchangeConfig": { "grantType": "TOKEN_EXCHANGE", "tokenExchangeGrantTypeConfig": { "actorTokenContent": "NONE" } } } } }'
Paramètres du client OAuth avec un fournisseur personnalisé utilisant l'authentification JWT par clé privée
| Paramètre | Obligatoire | Description |
|---|---|---|
|
|
Oui |
Définie sur |
|
|
Oui |
L'identifiant du client enregistré auprès de votre fournisseur d'identité. |
|
|
Oui |
ARN complet de la clé de signature KMS asymétrique. Doit se trouver dans la même région que le fournisseur d'informations d'identification. Cross-account pris en charge. |
|
|
Oui |
Algorithme de signature du JWT. L'un des : |
|
|
Non |
Revendications d'en-tête JWT supplémentaires (carte, 10 entrées maximum). Utilisez-le pour transmettre un |
|
|
Non |
Réclamations de charge utile JWT supplémentaires (carte, 10 entrées maximum). Impossible de remplacer |
|
|
Facultatif |
Omettre lors de l'utilisation de la clé privée JWT. |