Comment invalider jeton OAuth lorsque le mot de passe est changé?

Nous utilisons ASP.NET l'Identité dans un projet d'Api Web avec SimpleAuthorizationServerProvider, nous utilisons le protocole OAuth-des jetons pour autoriser chaque demande du client. (Jetons, et viennent à échéance laps de temps, nous n'utilisons pas d'actualisation des jetons.)

Lorsque les utilisateurs de changer leur mot de passe, je tiens à invalider les jetons qu'ils peuvent avoir, éventuellement sur d'autres appareils. Est-il de toute façon explicitement de le faire? J'ai testé et vu que les jetons de travail sans aucun problème après un changement de mot de passe, ce qui devrait être évité.

J'ai pensé à mettre le hachage de mot de passe, ou d'une partie de la valeur de hachage dans le jeton OAuth comme une revendication, et la validation dans le OnAuthorization la méthode de notre dérivés AuthorizeAttribute filtre.

Serait-ce une bonne façon de résoudre le problème?

N'est-ce pas en partie avec OAuth qu'il est indépendant lors de changements de Mot de passe? Pourquoi ne pas simplement supprimer le jeton à partir de votre serveur d'Authentification lorsqu'ils changent le mot de passe puis si ils essaient de l'utiliser sur d'autres périphériques, cela ne marchera pas.
"Pourquoi ne pas simplement supprimer le jeton à partir de votre serveur d'Authentification": est-ce possible avec ASP.NET l'Identité? Je pensais que les jetons sont autonomes, de sorte qu'ils peuvent être utilisés sur n'importe quel serveur web instance, et donc nous n'avons pas de serveur d'Authentification.
Si c'est vrai, ça sonne comme si j'avais besoin d'un rappel sur "ASP.NET l'Identité" sa fait un moment. Désolé.

InformationsquelleAutor Mark Vincze | 2014-11-06

12

Je ne recommande pas de mettre le hachage du mot de passe de la réclamation, et je crois qu'il n'y a pas de moyen direct d'invalider jeton lorsque le mot de passe est changé.

Mais si vous êtes Ok avec les coups de la DB avec chaque demande d'envoyer à partir de l'application client à un API protégé point de fin, alors vous avez besoin pour stocker Jeton Guid (Identificateur peut-être) pour chaque jeton accordée pour le propriétaire de la ressource demandée. Vous pouvez ensuite affecter le jeton Identifiant comme une revendication personnalisée pour ce jeton, après cela, vous devez cocher cette table avec chaque demande de recherche pour le jeton de l'identificateur et le nom d'utilisateur pour le propriétaire de la ressource.

Une fois le mot de passe est changé, vous supprimez ce jeton identificateur d'enregistrement pour cette ressource propriétaire (utilisateur) et la prochaine fois que le jeton envoyé par le client, il sera rejeté parce que le dossier de ce jeton identificateur de ressource et de propriétaire a été supprimé.
- C'était simple à mettre en place et fonctionne correctement. Merci!
- Content que cela a été utile. Si vous souhaitez pourquoi ne pas partager une partie du code que vous avez créé pour mettre en œuvre la présente, je suis sûr que ce sera utile pour les autres 🙂
- J'ai posté quelques détails du code.
- Dans la question ci-dessus disons que le scénario est le même, cependant au lieu de changer le mot de passe de l'utilisateur, essayez de vous connecter sur trois différentes de l'appareil et je ne veux que ce jeton doit travailler sur lequel l'Utilisateur s'est connecté récemment et au cours des deux jeton de deux autres appareil doit être révoquée/supprimer. Est-il possible de l'obtenir?
- putain je ne peux pas croire que je suis en train de lire ceci. MS a fait une autre bouse
InformationsquelleAutor Taiseer Joudeh
12

Je l'ai basé mon approche sur Taiseer de la suggestion. L'essentiel de la solution est la suivante. Chaque fois qu'un utilisateur modifie son mot de passe (et quand les registres), un nouveau GUID est générée et enregistrée dans la base de données dans la table User. J'appelle ce GUID le mot de passe timbre, et de le stocker dans une propriété appelée LatestPasswordStamp.

Ce timbre doit être envoyé au client dans le cadre de l'jeton comme une revendication. Ceci peut être obtenu avec le code suivant dans la GrantResourceOwnerCredentials méthode de la OAuthAuthorizationServerProvider-la mise en œuvre.
```
identity.AddClaim( new Claim( "PasswordTokenClaim", user.LatestPasswordStamp.ToString() ) );
```
Ce timbre va être envoyé par le client au serveur à chaque requête, et il est vérifié que le timbre n'a pas été modifié dans la base de données. Si elle l'est, cela signifie que l'utilisateur a changé leur mot de passe, éventuellement à partir d'un autre appareil. La vérification est effectuée dans notre coutume d'autorisation de filtre comme ceci.
```
public class AuthorizeAndCheckStampAttribute : AuthorizeAttribute
{
    public override void OnAuthorization( HttpActionContext actionContext )
    {
        var claimsIdentity = actionContext.RequestContext.Principal.Identity as ClaimsIdentity;
        if( claimsIdentity == null )
        {
            this.HandleUnauthorizedRequest( actionContext );
        }

        //Check if the password has been changed. If it was, this token should be not accepted any more.
        //We generate a GUID stamp upon registration and every password change, and put it in every token issued.
        var passwordTokenClaim = claimsIdentity.Claims.FirstOrDefault( c => c.Type == "PasswordTokenClaim" );

        if( passwordTokenClaim == null )
        {
            //There was no stamp in the token.
            this.HandleUnauthorizedRequest( actionContext );
        }
        else
        {
            MyContext ctx = (MyContext)System.Web.Mvc.DependencyResolver.Current.GetService( typeof( MyContext ) );

            var userName = claimsIdentity.Claims.First( c => c.Type == ClaimTypes.Name ).Value;

            if( ctx.Users.First( u => u.UserName == userName ).LatestPasswordStamp.ToString() != passwordTokenClaim.Value )
            {
                //The stamp has been changed in the DB.
                this.HandleUnauthorizedRequest( actionContext );
            }
        }

        base.OnAuthorization( actionContext );
    }
}
```
De cette façon, le client obtient une autorisation d'erreur si on tente d'autoriser lui-même avec un jeton qui a été délivré avant le mot de passe a été changé.
- Solution sympa, n'Est-il pas de manière officielle qui OAuth nous suggère de gérer de tels cas? Je veux dire qu'il semble être un sérieux trou dans l'ensemble du schéma d'authentification si tous les périphériques peuvent toujours accéder à une fois le mot de passe a été changé.
- Ouais, je pense que le problème ici est que OAuth lui-même n'en sait rien, où les identités viennent, c'est de la responsabilité du fournisseur d'identité. Par exemple, ici ASP.NET l'Identité, et le haut-OAuth gestionnaire d'installations sont séparées et ne connaissent pas les uns les autres, c'est pourquoi nous avons manuellement laisser le jeton gestionnaire de savoir que le mot de passe a été changé.
- Serait ma solution proposée ci-dessous selon votre expérience? stackoverflow.com/questions/29534111/...
- Merci d'avoir pris le temps de poster les détails sur la solution qui a fonctionné pour vous!
- Une solution plus simple dans le même sens serait de vérifier le jeton émis en date contre le mot de passe de la dernière date de modification (stockées dans la base de données). Cela permettrait d'économiser avoir à générer et de stocker et de faire passer le GUID.
- vous devriez donner l'exemple en tant qu'une réponse serait utile!
InformationsquelleAutor Mark Vincze

Vous devez vous connecter pour publier un commentaire.