asp.net web api - tutorial - Uso de JWT para implementar Autenticación en la API web de Asp.net

web api ejemplo

Question

He estado leyendo sobre JWT.

Pero por lo que leí, no es un mecanismo de autenticación, sino más bien un componente crucial en un mecanismo de Autenticación.

He implementado actualmente una solución que funciona, pero sólo era para probar JWT y ver cómo funciona. Pero lo que busco ahora es cómo se debe hacer uso de ella. Desde mi experiencia de ella es básicamente sólo un mecanismo de cifrado que proporciona una clave de cifrado única. También es capaz de poner la información en el interior de esta ficha.

Estoy queriendo ponerla en práctica en términos de un ASP.NET Web API 2 para ser consumido por una aplicación móvil.

Así que paso 1:

1. aplicación => Servidor: Iniciar sesión (usuario, pasword)
2. Servidor => aplicación: Login OK, aquí está su JWT
3. aplicación => servidor: Obtener perfil (JWT envía la petición) Server descifra JWT y determina la identidad solicitudes.

Ahora bien, esto es sólo mi comprensión de la misma, Mira yo podría estar en el camino totalmente equivocado.

Es el ideal de JWT para que usted no tiene que autenticarse en cada petición? Yo sólo autenticar las credenciales de los usuarios una vez (en el primer inicio de sesión) y después de allí en el servidor simplemente puede usar JWT y no tienen que buscar el pw usuarios y usuarios en la base de datos?

Sólo quiero usar la JWT a la Identidad quién es el usuario. entonces voy a autorizar a continuación, después que los haya autenticado. Como sé que hay una gran confundido con el nuevo MVC y autenticación y autorización.

Así que lo que mi pregunta se reduce a.

¿Cómo puedo manera segura y efectiva implementación de un mecanismo de autenticación mediante los JWT? No quiero que acaba de toser algo que parece funcionar y no tener ninguna idea de las implicaciones de seguridad. Estoy seguro de que existe una fuente en algún lugar que posiblemente ha diseñado un mecanismo de seguro que se adapte a mis necesidades.

Mis requisitos son:

• Sólo debe tener para comprobar DB para credenciales de los usuarios una vez fuera por sesión? Debido a la utilización de bcrypt utilizando una gran cantidad de recursos para comparar las contraseñas.
• Debe ser capaz de identificar al usuario de su petición. (Ie quiénes son, userId será suficiente) y, preferiblemente, sin acceder a la DB, así
• Debe ser tan bajo como sea posible sobrecarga, en lo que respecta a los recursos a nivel de servidor al procesar la solicitud.
• Si un intruso tuvo que copiar un dispositivos solicitud anterior, entonces no debe ser capaz de acceder a los datos de los usuarios reales. (obviamente)

Gracias

Answer 1

Escribí una publicación de blog detallada sobre cómo configurar el servidor de autorización OWIN para que emita tokens web JSON firmados en lugar de un token predeterminado. Por lo tanto, los servidores de recursos (Audiencia) pueden registrarse con el servidor Autorización y luego pueden usar los testigos JWT emitidos por la parte emisora ​​Token sin la necesidad de unificar los valores de machineKey entre todas las partes. Puede leer el token web JSON posterior en ASP.NET Web API 2 usando Owin

Answer 2

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

Autenticacion y autorizacion

• JWTs no tienen nada que ver con la autenticación. Golpear a su base de datos y contraseñas hash sólo ocurre cuando se autentica en la creación de la JWT. Este es ortogonal a JWTs y se puede hacer eso en cualquier forma que desee. Personalmente me gusta de miembro de reinicio , que también tiene un buen ejemplo del uso de JWTs.
• En teoría, usted podría tener el usuario introduzca una contraseña una vez al año y tienen la JWT sea válido ese año entero. Esto probablemente no es la mejor solución, si el JWT es robado en cualquier punto se vería comprometido los recursos de los usuarios.

Cifrado

• Las fichas pueden, pero no tienen que ser cifrados. Cifrando sus fichas aumentará la complejidad de su sistema y la cantidad de cómputo su servidor necesita leer los JWTs. Esto podría ser importante si necesita que nadie es capaz de leer el token cuando está en reposo.
• Los créditos son siempre criptográficamente firmados por el emisor para garantizar su integridad. Lo que significa que no pueden ser manipulados por el usuario o un tercero.

Reclamaciones

Sus JWTs pueden contener cualquier información que desee. El nombre de usuario, fecha de nacimiento, correo electrónico, etc. Esto se hace con la autorización basada en reclamaciones. A continuación, sólo dice a su proveedor para que una JWT con estas afirmaciones desde el principio de Reclamaciones. El código siguiente es de este ejemplo de miembro de reinicio y se 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 de su procesador.

Implementación

Una forma muy sencilla de implementar un proveedor Token es usar el Servidor de autorización OAuth de Microsoft en su proyecto WebAPI. Te da los huesos de lo que necesitas para hacer un servidor OAuth para tu API.

También puede consultar el 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 un cierto período 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 revocarse, mientras que los JWT no pueden. La desventaja de esta solución es que necesita configurar otro servidor o dos para alojar el servicio Identity.

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

Si está protegiendo algo extremadamente sensible, debe mantener la vida útil del token en un lapso de tiempo muy corto. Si está protegiendo algo menos sensible, podría prolongar la vida útil. Cuanto más largo sea el token si es válido, mayor será la cantidad de tiempo que un atacante tendrá que suplantar al usuario autenticado si la máquina del usuario está en peligro.