De retour d'erreur sur pas valide ou a expiré jeton
Je suis en train de mettre en œuvre le protocole OAuth Porteur d'Authentification avec Owin. Quand pas valide ou a expiré jeton est transmis, l'implémentation par défaut est de vous connecter cela comme un avertissement, et il suffit de ne pas définir une Identité. J'ai toutefois voudrais rejeter la demande en entier avec une erreur dans ce cas. Mais comment pourrais-je faire cela?
Après en fouillant dans le code que j'ai découvert que dans le OAuthBearerAuthenticationHandler
il analyse le jeton à l'aide d'un mécanisme de secours lorsque la condition AuthenticationTokenProvider
ne pas analyser les billet (comme l'implémentation par défaut). Ce gestionnaire de journal d'un avertissement lorsque le jeton n'a pas pu être analysé pour tout billet ou quand il a expiré.
Mais je ne trouve pas de place pour brancher mon propre logique à ce qui se passe lorsque le jeton est pas valide ou a expiré. Je pourrais théoriquement vérifier cela sur mon propre dans le AuthenticationTokenProvider
, mais alors je l'ai ré-écrire la logique (= copier) pour la création et la lecture du jeton. Aussi ce qui semble juste de sortir de la place, car cela semble être la seule responsable de la création et de l'analyse des jetons. Aussi, je ne vois pas un moyen de brancher mon propre mise en œuvre de la OAuthBearerAuthenticationHandler
dans le OAuthBearerAuthenticationMiddleware
.
Apparemment, mon meilleur et plus propre coup serait ré-écrire tout le middleware, mais cela semble très exagéré.
Que dois-je l'ignorer? Comment aurais-je aller sur ce le meilleur?
edit:
Pour obtenir des éclaircissements. Je sais que par définition pas une identité, la demande sera rejetée avec 401 non autorisé plus tard dans l'API Web. Mais personnellement, je vois cela comme vraiment mauvais style, silencieusement de la déglutition d'un faux jeton d'accès sans aucune notification. De cette façon, vous n'obtenez pas de savoir que votre jeton est de la merde, vous avez juste à savoir que vous n'êtes pas autorisés.
OriginalL'auteur user3137652 | 2014-04-03
Vous devez vous connecter pour publier un commentaire.
J'ai eu un problème similaire, je pense que la réponse est à la fin, mais quelqu'un va venir ici avec un problème similaire:
J'ai utilisé ce package nuget pour valider l'authentification, mais je pense que n'importe quelle méthode peut aider: https://www.nuget.org/packages/WebApi.AuthenticationFilter. Vous pouvez lire sa documentation dans ce site https://github.com/mbenford/WebApi-AuthenticationFilter
AuthenticationFilter.cs
AuthenticationFailureResult.cs
Réponse exemples:
Polices et de l'inspiration de la documentation:
//github.com/mbenford/WebApi-AuthenticationFilter
//www.asp.net/web-api/overview/security/authentication-filters
OriginalL'auteur jleon
Ouais, je n'ai pas trouver la "bonne" solution pour ce faire,
D'accord, mais c'est ce que j'ai fait (avant de lire ton post). Je copie & collé trois owin classes, et fait en sorte qu'il met bien en Owins contexte, qui peut ensuite être vérifiées par d'autres gestionnaires.
Ensuite, j'ai écrit ma propre autorisation de filtre, qui sera appliqué à l'échelle mondiale:
mon WebApiConfig:
Comment mon configureOAuth ressemble:
Je vais essayer & obtenir ce à la branche principale de l'authentification oAuth middleware, il semble évident de cas d'utilisation, à moins que quelque chose m'échappe.
OriginalL'auteur Erti-Chris Eelmaa
Si l'authentification échoue (ce qui signifie le jeton est expiré), alors que la couche n'est pas définie par l'utilisateur, comme vous l'avez dit. C'est la couche d'autorisation (plus tard) pour rejeter l'appel. Donc, pour votre scénario, votre API Web aurait besoin de refuser l'accès à un visiteur anonyme. L'utilisation de la [Autoriser] autorisation de filtre d'attribut.
Je serais heureux si vous pouviez supprimer votre réponse, car il ne répond pas à ma question. J'ai édité ma question et de préciser que je suis conscient de cela, et que ce n'est pas ce que je veux.
Désolé que vous n'aimez pas la réponse, mais c'est de la bonne conception. L'authentification est distincte de l'autorisation. Dan Roth de Microsoft a même des points dans cette version récente session: channel9.msdn.com/Events/Build/2014/3-603
Je n'ai jamais soutenu que, je sais que l'authentification et l'autorisation sont deux choses différentes. Mais je veux simplement rejeter valide de tentatives d'authentification avec un message d'erreur, pas silencieusement à les avaler. Il est également inutile de journal d'un avertissement (comme la mise en œuvre), si je ne peux pas réagir correctement.
Il est bon d'avoir le code supplémentaire pour discerner la raison de la 401. Nous avons besoin de distinguer entre expiré, invalides et des autorisations insuffisantes
OriginalL'auteur Brock Allen