Uso de JWT para implementar la autenticación en Asp.net api WEB

Su comprensión de los JWT es buena. Pero aquí hay un par de correcciones y algunas recomendaciones.

Autenticación y Autorización

• Los JWT no tienen nada que ver con la autenticación. Golpear su base de datos y contraseñas de hash solo ocurre cuando se autentica en la creación del JWT. Esto es ortogonal a JWTs y puedes hacerlo de cualquier manera que quieras. Personalmente me gusta Membership Reboot, que también tiene un buen ejemplo de uso de JWTs.
• Teóricamente, usted podría hacer que el usuario ingrese una contraseña una vez al año y que el JWT sea válido todo ese año. Lo más probable es que no sea la mejor solución, si el JWT es robado en cualquier momento, los recursos de los usuarios se verían comprometidos.

Cifrado

• Los tokens pueden, pero no tienen que estar encriptados. Cifrar sus tokens aumentará la complejidad de su sistema y la cantidad de computación que su servidor necesita para leer los JWTs. Esto puede ser importante si requiere que nadie sea capaz de leer el token cuando está en reposo.
• Los tokens siempre están firmados criptográficamente por el emisor para garantizar su integridad. Lo que significa que no pueden ser manipulados por el usuario o un tercero.

Reclamaciones

Sus JWT pueden contener cualquier información que desee. El nombre del usuario, fecha de nacimiento, correo electrónico, etc. Usted hace esto con una autorización basada en reclamos. A continuación, simplemente dígale a su proveedor que haga un JWT con estas reclamaciones del Principio de Reclamaciones. El siguiente código es de esa Membresía Ejemplo de reinicio y le muestra cómo se hace esto.

public override Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
    var svc = context.OwinContext.Environment.GetUserAccountService<UserAccount>();
    UserAccount user;
    if (svc.Authenticate("users", context.UserName, context.Password, out user))
    {
        var claims = user.GetAllClaims();

        var id = new System.Security.Claims.ClaimsIdentity(claims, "MembershipReboot");
        context.Validated(id);
    }

    return base.GrantResourceOwnerCredentials(context);
}

Esto le permite controlar con precisión quién está accediendo a sus recursos, todo sin golpear el servicio de autenticación intensivo del procesador.

Aplicación

Una forma muy fácil de implementar un proveedor de tokens es usar el servidor de autorización OAuth de Microsoft en su proyecto WebAPI. Le da los fundamentos básicos de lo que necesita para hacer un servidor OAuth para su API.

Usted también podría mirar en Servidor de identidad de Thinktecture que le daría un control mucho más fácil sobre los usuarios. Por ejemplo, puede implementar fácilmente tokens de actualización con el servidor de identidad donde el usuario se autentica una vez y luego durante una cierta cantidad de tiempo (tal vez un mes) pueden continuar recibiendo JWT de corta duración del Servidor de identidad. Los tokens de actualización son buenos porque pueden ser revocados, mientras que los JWT no pueden. La desventaja de esta solución es que necesita configurar otro servidor o dos para alojar el Servicio de identidad.

Para lidiar con su último punto, que un intruso no debería ser capaz de copiar la última solicitud para obtener acceso a un recurso, debe usar SSL como mínimo. Esto protegerá el token en el transporte.

Si está protegiendo algo extremadamente sensible, debe mantener la vida útil del token en un período de tiempo muy corto. Si usted está protegiendo algo menos sensible, usted podría hacer la vida más larga. Cuanto más largo sea el token si es válido, más grande la ventana de tiempo que un atacante tendrá que hacerse pasar por el usuario autenticado si la máquina del usuario está comprometida.