Revendications SHR personnalisées

En tant qu’amélioration de la preuve de possession du jeton d’accès, MSAL Browser fournit un moyen d’insérer des revendications personnalisées du client dans un Signed HTTP Request, également appelé PoP Token. Ces revendications SHR personnalisées peuvent être ajoutées à n’importe quelle demande de jeton qui utilise le POP schéma d’authentification.

Étant donné que la charge utile d’une Signed HTTP Request a un format spécifique, au lieu d’autoriser des noms de revendications personnalisés qui pourraient entrer en conflit avec l’une des revendications SHR de premier ordre, MSAL Browser permet de transmettre des revendications client personnalisées sous forme de chaîne de caractères, qui sera ajoutée à la requête HTTP signée JWT comme valeur d’une revendication appelée client_claims. Cette chaîne est généralement un objet sérialisé contenant les revendications personnalisées, mais MSAL n’analyse pas ou ne vérifie pas la chaîne de quelque manière que ce soit.

Étant donné que MSAL ne met pas en cache Signed HTTP Requests (le secret du jeton d’accès est mis en cache et que la charge utile SHR est générée et signée juste-à-temps chaque fois qu’elle acquireTokenSilent est appelée), les revendications client personnalisées ne seront pas mises en cache non plus. Cela signifie que les revendications doivent également être transmises à chaque appel acquireTokenSilent pour qu’elles soient ajoutées au SignedHTTPRequest résultant.

Une fois le Signed HTTP Request envoyé au serveur de ressources en tant que PoP Token, le serveur de ressources est chargé de valider la charge utile signée ainsi que d’extraire et d’analyser le client_claims.

Usage

Les déclarations personnalisées du client pour les SHRs peuvent être transmises dans n’importe quel objet de demande de jeton sous la forme de shrClaims. Il est important de noter que les revendications SHR personnalisées sont une extension du schéma de preuve de possession du jeton d’accès ; elles ne seront donc utilisées que lorsque le authenticationScheme de la demande de jeton est défini sur POP.

Exemple de requête de redirection pour l’obtention d’un jeton

const popTokenRequest = {
    scopes: ["User.Read"],
    authenticationScheme: msal.AuthenticationScheme.POP,
    resourceRequestMethod: "POST",
    resourceRequestUri: "YOUR_RESOURCE_ENDPOINT",
    shrClaims: "{\"nonce\": \"AQAA123456\",\"local_nonce\": \"AQAA7890\"}"
}

Une fois la demande configurée et POP définie en tant que authenticationScheme, elle peut être envoyée à l’API acquireTokenRedirect MSAL Browser.

const response = await myMSALObj.acquireTokenRedirect(popTokenRequest);

La réponse contiendra une propriété appelée accessToken, qui contiendra le Signed HTTP Request. Lorsque vous avez vérifié l’utilisation de la clé publique, la charge utile JWT de SHR se présente comme suit :

{
    at: ...,
    ts: ...,
    m: "POST",
    u: "YOUR_RESOURCE_ENDPOINT",
    nonce: ...,
    p: ...,
    q: ...,
    client_claims: "{\"nonce\": \"AQAA123456\",\"local_nonce\": \"AQAA7890\"}"
}