Ok le problème est ici:
bien que vous avez configuré votre disposition Identité correctement les ressources (à la fois standard et personnalisés), vous devez également définir explicitement ceux qui sont une nécessité lors de l'appel de votre api de ressources. Afin de définir ce que vous devez aller pour votre Config.cs
classe ExampleIdentityServer
projet et de fournir un troisième argument, comme sur l' new ApiResouirce
constructeur. Seuls ceux-ci seront inclus dans l' access_token
// scopes define the API resources in your system
public static IEnumerable<ApiResource> GetApiResources()
{
return new List<ApiResource>
{
new ApiResource("api1", "My API", new[] { JwtClaimTypes.Subject, JwtClaimTypes.Email, JwtClaimTypes.Phone, etc... })
};
}
En substance, cela signifie que j'ai eu mon identité des revendications configuré pour mon organisation, mais il peut y avoir plus d'une Api impliquées et non l'ensemble de l'Api de faire usage de tous les profil de revendications. Cela signifie également que ces sera présent à l'intérieur de votre ClaimsPrincipal
tout le reste sera toujours possible d'accéder par le biais de la "userinfo" comme un point de terminaison http appel.
REMARQUE: en ce qui concerne l'actualisation des jetons:
Si vous avez choisi d'activer l'actualisation des jetons via AllowOfflineAccess = true
, vous pouvez rencontrer le même comportement lors de l'actualisation de l'access_token "GetProfileDataAsync n'a pas exécuté!". Donc, les revendications à l'intérieur de l'access_token rester le même, bien que vous obtenez une nouvelle access_token avec mise à jour à vie. Si c'est le cas, vous pouvez les forcer à toujours actualiser à partir du Profil de service en définissant UpdateAccessTokenClaimsOnRefresh=true
sur la configuration du client.