1
votes

Identity Server 4 Demandes d'étendue liées à l'identité, mais pas d'étendue openid

J'essaie d'ajouter une ressource / portée personnalisée et pour mes tests, je l'ai choisie comme courrier électronique, mais si je comprends bien, cela peut avoir n'importe quelle valeur. Donc, pour mes ressources, j'ai ceci:

AllowedScopes = new List<string>
{
    "openid", "profile", "email", "test"
}

Ensuite, pour les portées sur le client, c'est comme suit:

return new List<IdentityResource>
{
    new IdentityResources.OpenId(),
    new IdentityResources.Profile(),
    new IdentityResource("email", "Email", new [] { "email" })
    //new IdentityResources.Email()  -- This was tried as well, same error.
};

return new List<ApiResource> { new ApiResource("test", "Test") };

Cependant, lorsque je demande un jeton avec http: // localhost: 5000 / connect / authorize? Scope = test email les erreurs de page et dans mes bas je vois

2019-07-05 11: 08: 00.681 -04: 00 [ERR] Portée non valide: email
2019-07-05 11: 08: 00.684 -04: 00 [ERR] La validation de la demande a échoué

Je ne sais vraiment pas où je me suis trompé. Selon tous les documents et messages SO que j'ai trouvés, voici comment procéder.

EDIT: Il y avait un bogue interne qui a été négligé et causait une erreur List passé. Cependant, même après avoir résolu cela, cela pose toujours un problème avec un message d'erreur différent maintenant:

Demandes d'étendue liées à l'identité, mais pas d'étendue openid

Edit 2:

Après un formulaire d'aide d_f, j'ai réalisé que j'avais besoin de mettre à jour ma requête qui ressemble maintenant à ceci:

/ connect / authorize? scope = test openid email & response_type = id_token token & nonce = NONCE

Je suis maintenant autorisé et je peux voir la portée de l'e-mail dans les revendications. Cependant, même si je considère l'e-mail comme un champ d'application, je ne vois l'e-mail réel nulle part dans les revendications.


1 commentaires

votre demande a manqué la portée openid . le seul toujours requis par le protocole


3 Réponses :


0
votes

Le courrier électronique est une ressource d'identité standard.

Essayez

return new List<IdentityResource>
{
  new IdentityResources.OpenId(),
  new IdentityResources.Profile(),
  new IdentityResources.Email()
}; 

Voir documentation

Si vous souhaitez en ajouter une personnalisée, vous pouvez la trouver ici


11 commentaires

Je ne pense pas que ce soit le problème, je peux le changer pour n'importe quel nom et j'ai le même problème.


L'ID client est absent de la demande d'authentification. Est-ce qu'il manque également dans votre code ou vous venez de le supprimer pour garder la question propre?


J'ai mis à jour ma question, j'ai résolu pourquoi cette erreur spécifique se produisait, mais une autre a pris sa place maintenant. Aussi qu'entendez-vous par demande d'authentification? De quelle fonction dites-vous que l'identifiant manque et que je vérifierai?


Votre demande d'autorisation doit contenir client_id localhost: 5000 / connect / authorize? Client_id = {yourClientId} & sc‌ ope = test email mais maintenant je vois votre question mise à jour, et je pense que ce sera autre chose. Je n'ai jamais vu cette erreur auparavant, je dois vérifier.


Oui, le clientId est passé. En fait, tout fonctionne bien si je n'essaye pas de demander l'e-mail de portée. si je demande seulement un test, cela passe bien et je peux utiliser mes API avec ce jeton.


@Bojan lorsque vous ne demandez pas la portée openid, le protocole passe à oauth. ce n'est pas grave sauf si vous demandez des étendues d'identité - une extension ajoutée par openid connect


@d_f alors vous dites dans le cadre de ma demande que je dois inclure openid dans les portées? J'ai déjà essayé mais j'ai toujours la même erreur. Est-ce que je manque quelque chose?


@d_f En fait, j'ai menti, désolé, l'erreur est la suivante si j'ajoute openid comme l'une des étendues dans ma demande Les demandes de type de réponse de jeton doivent uniquement inclure des étendues de ressources, mais pas d'étendues d'identité.


@Bojan bien alors. votre demande d ' identité doit contenir & response_type = id_token% 20token (en cas de flux implicite)


@d_f il semble que les erreurs ne font que s'accumuler. Voici ce que j'ai essayé: / connect / authorize? Scope = test openid email & response_type = id_token token et l'erreur que j'obtiens est Nonce requis pour un flux implicite et hybride avec une portée openid


l'heure était proche du week-end, je devais partir :) mais finalement j'ai rajouté un peu sur nonce ... chat.stackoverflow.com/rooms/196055/...



0
votes

Vous ajoutez la revendication IdentityResources.Email () dans IdentityResource , ce qui signifie que id_token inclura les informations de messagerie de l'utilisateur. Vous pouvez décoder le id_token (pas le jeton d'accès) à l'aide d'un outil en ligne tel que https://jwt.io/ pour vérifier les réclamations retournées.

Vous pouvez également définir AlwaysIncludeUserClaimsInIdToken sur true dans la configuration du client pour voir si elle inclut la réclamation par e-mail:

new Client
{
    ClientId = "mvc",
    ClientName = "MVC Client",
    AllowedGrantTypes = GrantTypes.HybridAndClientCredentials,

    ....

    ....
    AlwaysIncludeUserClaimsInIdToken = true,
    AllowedScopes =
    {
        IdentityServerConstants.StandardScopes.OpenId,
        IdentityServerConstants.StandardScopes.Profile,
        "api1",
        IdentityServerConstants.StandardScopes.Email,
    },
    AllowOfflineAccess = true
},

De plus, il existe différents types (flux d'authentification) d'exemples de démarrage rapide d'IdentityServer 4:

https://github.com/IdentityServer/IdentityServer4/tree/master/samples/Quickstarts

Vous pouvez démarrer pour personnaliser le client / IDS4 en fonction des exemples de code.


0 commentaires

1
votes

Je vois que la réponse nécessite des connaissances théoriques. Comme vous pouvez le trouver dans n'importe quel travail fondamental ou dans la spécification originale, OpenID Le protocole Connect est devenu une combinaison d'OpenId et d'OAuth. OIdC est compatible avec le second, comme vous avez pu le constater lors de votre transformation de requête. Ce qui est nouveau pour OIdC est un jeton d'identité supplémentaire. OAuth introduit le jeton accès aka porteur + jeton d'actualisation pour obtenir un nouvel accès lorsque l'existant expire. Tout cela concerne l'accès à l'API à l'aide de l'en-tête http d'autorisation du porteur. Et le nouveau jeton d'identité représente une session utilisateur pour l'application, pas une api.

La charge utile pour identity_token et access_token dans le serveur d'identité 4 est contrôlé par deux dictionnaires distincts IdentityResources a > et ApiResources en conséquence. Malheureusement, vous ne pouvez pas ajouter une portée dans les deux en même temps. Mais vous pouvez définir deux étendues différentes avec la même revendication. Par exemple:

public static IEnumerable<ApiResource> GetApiResources()
{
    return new List<ApiResource>
    {
        new ApiResource
        {
            Name = "test-api",
            Scopes =
            {
                new Scope
                {
                    Name = "test",
                    UserClaims =
                    {
                        JwtClaimTypes.SessionId,
                        JwtClaimTypes.Role,
                        Constants.TenantIdClaimType,
                        JwtClaimTypes.Email,
                        JwtClaimTypes.Locale
                    }
                }
            }
        }
    };
}

public static List<IdentityResource> GetIdentityResources()
{
    // Claims automatically included in OpenId scope
    var openIdScope = new IdentityResources.OpenId();
    openIdScope.UserClaims.Add(JwtClaimTypes.Locale);

    // Available scopes
    return new List<IdentityResource>
    {
        openIdScope,
        new IdentityResources.Profile(),
        new IdentityResources.Email(),
        new IdentityResource(Constants.RolesScopeType, Constants.RolesScopeType,
                    new List<string> {JwtClaimTypes.Role, Constants.TenantIdClaimType})
            {
                Required = true
            }
    };
}

Dans cet exemple, nous avons ajouté la possibilité d'obtenir une réclamation par e-mail dans access_token dans le cadre du test scope et dans id_token dans le cadre de la portée standard de email .

De plus, nous devons garder à l'esprit que le id_token code> est optimisé pour la taille par défaut et n'a que les revendications requises par le protocole dans sa charge utile. Toutes les réclamations supplémentaires peuvent être demandées en plus auprès du point de terminaison Userinfo de l'IdP. Pour obtenir toutes les revendications des utilisateurs dans le id_token , vous pouvez définir AlwaysIncludeUserClaimsInIdToken = true dans la configuration du client dans IdSrv.


0 commentaires