asp.net mvc 5 - studio - Web API 2 OWIN Bearer Token Propósito de la cookie?
web api ejemplo (3)
Intento comprender el nuevo proceso de autenticación de OWIN Bearer Token en la plantilla de aplicación de una sola página en MVC 5. Corrígeme si me equivoco, para el flujo de autenticación del cliente de contraseñas OAuth, la autenticación del token de portador funciona verificando el encabezado de solicitud de autorización HTTP para el código del token de acceso al Portador para ver si se autentica una solicitud, no confía en la cookie para verificar si una solicitud en particular está autenticada.
De acuerdo con esta publicación:
Autenticación de token de portador OWIN con muestra de API web
public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
using (IdentityManager identityManager = _identityManagerFactory.CreateStoreManager())
{
if (!await identityManager.Passwords.CheckPasswordAsync(context.UserName, context.Password))
{
context.SetError("invalid_grant", "The user name or password is incorrect.");
return;
}
string userId = await identityManager.Logins.GetUserIdForLocalLoginAsync(context.UserName);
IEnumerable<Claim> claims = await GetClaimsAsync(identityManager, userId);
ClaimsIdentity oAuthIdentity = CreateIdentity(identityManager, claims,
context.Options.AuthenticationType);
ClaimsIdentity cookiesIdentity = CreateIdentity(identityManager, claims,
_cookieOptions.AuthenticationType);
AuthenticationProperties properties = await CreatePropertiesAsync(identityManager, userId);
AuthenticationTicket ticket = new AuthenticationTicket(oAuthIdentity, properties);
context.Validated(ticket);
context.Request.Context.Authentication.SignIn(cookiesIdentity);
}
}
La función GrantReourceOwnerCredentials no solo compone el ticket con esta línea: context.Validated (ticket); pero también compone una identidad de cookie y la establece en la cookie con esta línea: context.Request.Context.Authentication.SignIn (cookiesIdentity);
Entonces mis preguntas son, ¿cuál es el propósito exacto de la cookie en esta función? ¿No debería el AuthenticationTicket ser lo suficientemente bueno para fines de autenticación?
En la plantilla SPA, en realidad hay dos mecanismos de autenticación separados habilitados: autenticación de cookies y autenticación de tokens. Esto permite la autenticación de las acciones del controlador MVC y Web API, pero requiere una configuración adicional.
Si busca en el método WebApiConfig.Register, verá esta línea de código:
config.SuppressDefaultHostAuthentication();
Eso le dice a la API Web que ignore la autenticación de cookies, lo que evita una serie de problemas que se explican en el enlace que publicó en su pregunta :
"... la plantilla SPA también habilita el middleware de cookie de aplicación como modo activo para habilitar otros escenarios como la autenticación MVC. Por lo tanto, la API web aún se autenticará si la solicitud tiene cookie de sesión pero sin un token de portador. Probablemente eso no sea lo que desea como sería venerable para los ataques CSRF para sus API. Otro impacto negativo es que si la solicitud no está autorizada, ambos componentes del middleware aplicarán desafíos. El middleware de cookies alterará la respuesta 401 a un 302 para redirigir a la página de inicio de sesión. Eso tampoco es lo que quieres en una solicitud de API web ".
Por lo tanto, ahora con la llamada a config.SuppressDefaultHostAuthentication() las llamadas a la API web que requieren autorización ignorarán la cookie que se envía automáticamente junto con la solicitud y buscarán un encabezado de autorización que comience con "portador". Los controladores MVC seguirán utilizando la autenticación de cookies y desconocen el mecanismo de autenticación de tokens, ya que no es una muy buena opción para la autenticación de la página web.
La cookie tiene un propósito importante. Su valor contiene el token de portador que se puede extraer mediante javascript del lado del cliente en sus páginas. Esto significa que si el usuario pulsa F5 o actualiza la página, la cookie generalmente persistirá. Su javascript del lado del cliente puede tomar el token del portador de la cookie cuando la página se recarga.
La existencia de la cookie también me dejó perplejo, ya que claramente no es necesario en un escenario de autenticación de token de portador ... En this publicación, el autor disecciona la plantilla de cuentas individuales y tiene lo siguiente para decir sobre la cookie:
El método también establece una cookie de aplicación. No veo una buena razón para eso.
Supongo que los autores de la plantilla querían mostrar ejemplos de diferentes tipos de lógica de autenticación, y en este caso particular querían mostrar cómo se podía almacenar la información de autenticación tanto en la carga útil JSON de autenticación de token de portador, como en una cookie de autenticación estándar.
El hecho de que la carga útil de autenticación JSON esté configurada para incluir también una propiedad no encriptada adicional (innecesaria) (la identificación del usuario), además del ticket encriptado, parece apoyar esta teoría:
var properties = CreateProperties(user.UserName);
var ticket = new AuthenticationTicket(oAuthIdentity, properties);
Parece que los autores de la plantilla querían proporcionar algunos ejemplos útiles, en lugar del mínimo necesario para lograr la autenticación token del portador. Esto también se menciona en la publicación vinculada arriba.