Informations d’identification de certificat d’authentification d’application de la Plateforme d’identités Microsoft

Article
04/10/2024

La plateforme d’identités Microsoft permet à une application d’utiliser ses propres informations d’identification pour l’authentification partout où une clé secrète client pourrait être utilisée, par exemple, dans le flux d’octroi d’informations d’identification du client OAuth 2.0 et le flux On-Behalf-Of (OBO).

Parmi les types d’informations d’identification qu’une application peut utiliser pour l’authentification figure l’assertion JSON Web Token (JWT) signée avec un certificat dont est propriétaire l’application. Cela est décrit dans la spécification OpenID Connect pour l'option d’authentification du client private_key_jwt.

Si vous êtes intéressé par l’utilisation d’un jeton JWT émis par un autre fournisseur d’identité comme informations d’identification pour votre application, consultez la Fédération des identités de charge de travail pour savoir comment configurer une stratégie de Fédération.

Format d’assertion

Pour calculer l’assertion, vous pouvez utiliser l’une des nombreuses bibliothèques JWT dans la langue de votre choix. Pour permettre cela, MSAL utilise .WithCertificate(). Les informations sont transmises par le jeton dans son En-tête , ses Revendications et sa Signature.

Paramètre	Remarque
`alg`	Doit être PS256
`typ`	Doit être JWT
`x5t#s256`	Empreinte SHA-256 encodée Base64url de l’encodage DER du certificat X.509.

Revendications (charge utile)

Type de revendication	Valeur	Description
`aud`	`https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token`	La revendication « AUD » (audience) identifie les destinataires auxquels le JWT est destiné (ici Microsoft Entra ID). Consultez RFC 7519, section 4.1.3. Dans ce cas, ce destinataire est le serveur de connexion (`login.microsoftonline.com`).
`exp`	1601519414	La revendication « exp » (délai d’expiration) indique le délai d’expiration après lequel le JWT ne doit pas être accepté pour traitement. Consultez RFC 7519, section 4.1.4. Cela permet à l’instruction d’être utilisée jusqu’à ce moment-là. Réduisez-la donc au minimum : 5 à 10 minutes après `nbf` au maximum. Microsoft Entra ID ne place actuellement aucune restriction sur l’heure de `exp`.
`iss`	{ClientID}	La revendication « ISS » (émetteur) identifie le principal qui a émis le jeton JWT ; le cas échéant, votre application cliente. Utilisez l’ID d’application GUID.
`jti`	(un guid)	La revendication « JTI » (ID JWT) fournit un identificateur unique pour le jeton JWT. La valeur de l’identificateur doit être assignée de manière à garantir qu’il y a une probabilité négligeable que la même valeur soit affectée par accident à un objet de données différent ; si l’application utilise plusieurs émetteurs, les collisions doivent également être évitées parmi les valeurs générées par différents émetteurs. La valeur « JTI » est une chaîne qui respecte la casse. RFC 7519, section 4.1.7
`nbf`	1601519114	La revendication « nbf » (pas avant) indique le délai avant lequel le JWT ne doit PAS être accepté pour être traité. RFC 7519, section 4.1.5. L’utilisation de l’heure actuelle est appropriée.
`sub`	{ClientID}	La revendication « SUB » (objet) identifie l’objet du jeton JWT ; le cas échéant, votre application également. Utilisez la même valeur que `iss`.
`iat`	1601519114	la revendication « iat » (émission à) identifie l’heure à laquelle le jeton JWT a été émis. Cette revendication peut être utilisée pour déterminer l’ancienneté du jeton JWT. RFC 7519, section 4.1.5.

Signature

La signature est calculée en appliquant le certificat, conformément à la spécification RFC7519 sur les jetons Web JSON. Utilisez le remplissage PSS.

Exemple d’une assertion JWT décodée

{
  "alg": "PS256",
  "typ": "JWT",
  "x5t#sha256": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u"
}
.
{
  "aud": "https: //login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/v2.0/token",
  "exp": 1484593341,
  "iss": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "jti": "00aa00aa-bb11-cc22-dd33-44ee44ee44ee",
  "nbf": 1484592741,
  "sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
}
.
"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u..."

Exemple d’une assertion JWT encodée

La chaîne suivante est un exemple d’assertion encodée. Si vous regardez attentivement, vous remarquerez les trois sections séparées par des points (.) :

La première section encode l’en-tête
La deuxième section encode les revendications (charge utile)
La dernière section est la signature calculée avec les certificats à partir du contenu des deux premières sections

"eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJhdWQiOiJodHRwczpcL1wvbG9naW4ubWljcm9zb2Z0b25saW5lLmNvbVwvam1wcmlldXJob3RtYWlsLm9ubWljcm9zb2Z0LmNvbVwvb2F1dGgyXC90b2tlbiIsImV4cCI6MTQ4NDU5MzM0MSwiaXNzIjoiOTdlMGE1YjctZDc0NS00MGI2LTk0ZmUtNWY3N2QzNWM2ZTA1IiwianRpIjoiMjJiM2JiMjYtZTA0Ni00MmRmLTljOTYtNjVkYmQ3MmMxYzgxIiwibmJmIjoxNDg0NTkyNzQxLCJzdWIiOiI5N2UwYTViNy1kNzQ1LTQwYjYtOTRmZS01Zjc3ZDM1YzZlMDUifQ.
Gh95kHCOEGq5E_ArMBbDXhwKR577scxYaoJ1P{a lot of characters here}KKJDEg"

Inscrire votre certificat auprès de la Plateforme d’identités Microsoft

Vous pouvez associer les informations d’identification du certificat à l’application cliente dans la plateforme d’identités Microsoft par le Centre d’administration Microsoft Entra en utilisant l’une des méthodes suivantes :

Chargement du fichier de certificat

Sous l’onglet inscriptions d'applications de l’application cliente :

Sélectionnez Certificats et secrets>Certificats.
Cliquez sur Charger un certificat et sélectionnez le fichier de certificat à charger.
Sélectionnez Ajouter. Une fois le certificat chargé, les valeurs d'empreinte numérique, de date de début et d’expiration s'affichent.

Mise à jour du manifeste d’application

Après l’acquisition d’un certificat, calculez les valeurs suivantes :

$base64Thumbprint -Valeur encodée en base64 du code de hachage du certificat
$base64Value -Valeur encodée en base64 des données brutes du certificat

Fournissez un GUID pour identifier la clé dans le manifeste de l’application ($keyId).

Dans l’inscription d’application Azure pour l’application cliente :

Sélectionnez Manifeste pour ouvrir le manifeste d’application.

Remplacez la propriété keyCredentials par les nouvelles informations de votre certificat, en utilisant le schéma suivant.

"keyCredentials": [
    {
        "customKeyIdentifier": "$base64Thumbprint",
        "keyId": "$keyid",
        "type": "AsymmetricX509Cert",
        "usage": "Verify",
        "value":  "$base64Value"
    }
]

Enregistrez les modifications du manifeste de l’application, puis chargez-le dans la Plateforme d’identités Microsoft.

La propriété keyCredentials peut avoir plusieurs valeurs. Vous pouvez donc charger plusieurs certificats pour une gestion plus élaborée des clés.

Utilisation d’une assertion de client

Les assertions de client peuvent être utilisées partout où une clé secrète client est utilisée. Par exemple, dans le flux du code d’autorisation, vous pouvez transmettre une client_secret pour prouver que la requête provient de votre application. Vous pouvez remplacer ceci par les paramètres client_assertion et client_assertion_type.

Paramètre	active	Description
`client_assertion_type`	`urn:ietf:params:oauth:client-assertion-type:jwt-bearer`	Il s’agit d’une valeur fixe, indiquant que vous utilisez les informations d’identification d’un certificat.
`client_assertion`	`JWT`	Il s’agit du JWT créé ci-dessus.

Étapes suivantes

La bibliothèque MSAL.NET gère ce scénario dans une seule ligne de code.

L’exemple de code Application console de démon .NET utilisant la plateforme d’identité Microsoft sur GitHub montre comment une application utilise ses propres informations d’identification pour l’authentification. Il montre également comment vous pouvez créer un certificat auto-signé à l’aide de la cmdlet PowerShell New-SelfSignedCertificate. Vous pouvez également utiliser les scripts de création d’application dans le référentiel d’échantillons pour créer des certificats, calculer l’empreinte, etc.

Partager via