Comment l'API Web de jetons d'accès validé sur le serveur?

Une fois un WebAPI jeton d'accès est généré, comment ne WebAPI valider ce jeton pour la prochaine demande? Je me demande si je peux utiliser une [Authorize] attribut, il faut comparer le jeton envoyé par le client avec le jeton sur le côté serveur, si le produit est stocké quelque part. Est-il juste de vérifier si le jeton est présent, et non de sa valeur?

Vous parlez des jetons d'accès, puis sur les cookies. Vous avez besoin de clarifier ce qui est de votre environnement. Êtes-vous à l'aide au porteur du jeton d'authentification dans OWIN? Veuillez ajouter un code d'authentification afin que nous puissions vous aider.
Oui, je suis en utilisant OWIN. Juste envie d'en savoir plus sur les jetons. Ma question est simple.
Avez-vous regardé Sécuriser une API Web avec des Comptes Individuels et Connexion Locale dans ASP.NET l'API Web 2.2?
À partir du lien @Igor fourni, je pense que vous allez lire un autre lien OWIN d'Autorisation OAuth 2.0 Serveur

OriginalL'auteur Mohan Sharma | 2016-05-29

  1. 14

    Porteur du jeton

    Tout d'abord, votre Fournisseur d'Identité ou Fournisseur de Jeton qui délivre l'autorisation de jetons doit avoir la même machine les paramètres essentiels comme l'application d'Api Web pour le chiffrement/déchiffrement:

    <machineKey
    decryptionKey="B7EFF1C5839A624ED0268917EDE82F408D2ECBFAC817"
    validation="SHA1"
    validationKey="C2B8DF31AB9624D8066DFDA1A479542825F3B48865C4E47AF6A026F22D853DEC2B3248DF268599BF89EF78B9E86CA05AC73577E0D5A14C45E0267588850B"
    /> </système.web>

    Car sous le capot Bearertoken utilise MachineKey de chiffrement.
    En d'autres termes, si vous n'avez pas les mêmes paramètres, votre api web ne sera pas en mesure de décrypter le jeton (valider).
    Ceci est fait automatiquement par:

    Microsoft.Owin.Security.OAuth.dll

    à l'aide du middleware.

    Vous pouvez utiliser le Autoriser Attribut sur votre site web api contrôleurs/actions si vous voulez simple avec l'autorisation de noms d'utilisateurs ou rôles comme ceci:

    [Authorize(Roles="Administrators,Managers",Users ="Mike,Laura")]

    Si vous voulez personnalisé autorisation, alors vous avez à mettre en œuvre une coutume de l'autorisation de l'attribut qui va gérer la coutume autorisation de votre site web api. Si l'utilisateur n'est pas autorisé à passer vous allez retourner 401 non autorisé Réponse:

    actionContext.Response = actionContext.Request.CreateResponse(HttpStatusCode.Unauthorized);
actionContext.Response.Headers.Add("WWW-Authenticate","Bearer location='http://localhost:8323/account/login'");

    Par exemple:

    [AttributeUsage(AttributeTargets.Method | AttributeTargets.Class)]
public class CustomAuthorizeAttribute : System.Web.Http.Filters.AuthorizationFilterAttribute
{
    public RulesExampleEnum[] Rules { get; set; }
    public string Id { get; set; }
    .....
//Summary:
//    Calls when a process requests authorization.
//
//Parameters:
//  actionContext:
//    The action context, which encapsulates information for using System.Web.Http.Filters.AuthorizationFilterAttribute.
public virtual void OnAuthorization(HttpActionContext actionContext);
public virtual Task OnAuthorizationAsync(HttpActionContext actionContext, CancellationToken cancellationToken);

    et de l'inscrire dans votre webApiConfig.cs

    config.Filters.Add(new CustomAuthorizeAttribute());

    et de l'appliquer sur l'Api Web de contrôleur ou de l'action:

    [CustomAuthorize(Id = "AnyId", Rules = new RulesExampleEnum[] { RulesExampleEnum.Rule1, RulesExampleEnum.Rule3 })]
public IEnumerable<object> Get()
{...
    Cela a été une bouée de sauvetage pour moi, c'est exactement ce que nous essayons de faire, là où une API de consommation authentification HTTP basic auth (pour identifier la machine, pour le contrôle d'accès) et ensuite, nous voulons un jeton OAUTH (pour identifier l'utilisateur, pour l'autorisation / contrôle d'identité).

    OriginalL'auteur Legends

  2. 4

    Une fois le jeton d'accès est généré, le client doit inclure le jeton d'accès à l'intérieur de l'en-Tête pour chaque demande.

    Client peut régler le jeton d'accès à l'intérieur de Authorization en-Tête HTTP.

    Sur le côté serveur, vous devez créer une classe pour gérer l'Autorisation, qui est un dérivé de la classe de System.Web.Http.AuthorizeAttribute, quelque chose comme ci-dessous :

    public class AuthorizationHandlerAttribute : AuthorizeAttribute
{
    string AccessTokenFromRequest = "";
    if (actionContext.Request.Headers.Authorization != null)
    {
        //get the access token
        AccessTokenFromRequest = actionContext.Request.Headers.Authorization.Parameter;
    }

    string AccessTokenStored = ""; 
    //write some code to get stored access token, probably from database 
    //then assign the value to a variable for later use

    //compare access token
    if (AccessTokenFromRequest != AccessTokenStored)
    {
        //if the token is not valid then return 401 Http Stasus
        //or simply call base method 
        base.HandleUnauthorizedRequest(actionContext);
    }
}

    Puis vous utilisez la classe nouvellement créée et l'attacher sur controller ou action vous souhaite protéger contre tout accès non autorisé.

    public class UsersController : ApiController
{
    [AuthorizationHandler]
    public User Get(int id)
    {
        //only request with valid access token will reach this 
    }
}

    OriginalL'auteur Michael

  3. 3

    La clé secrète est transmis dans le en-tête de la demande du client vers le serveur, et les contenus sont validés au serveur à chaque requête lorsque l'attribut [Authorize] est utilisé.

    Vous pouvez utiliser un outil comme Fiddler de Telerik (gratuit) pour voir les données transportées, mais pas le contenu (depuis sa crypté). L'inspection de raw du trafic web est inestimable lorsque vous travaillez avec MVC /WebAPI, donc je le recommande fortement. Voici un lien vers Fiddler, bien que d'autres outils similaires existent également.

    http://www.telerik.com/fiddler

    Pour répondre à la deuxième partie de votre question, le serveur absolument vérifie le contenu de la clé secrète avant d'autoriser la demande de procéder dans les cas autorisés.

    cela a sauvé ma journée

    OriginalL'auteur HBomb