filters - web api custom authentication

Web API 2, Autenticación OWIN, SignOut no cierra la sesión

Question

Investigo un poco para trabajar con el uso de tokens de portador como un mecanismo de autenticación (es decir, la interfaz de usuario de AngularJS, se autentica mediante OWIN en un proyecto de API web [2]).

Tengo el inicio de sesión funcionando bien, la información del rol y todo está bien, pero no puedo hacer que el token cierre la sesión.

Mi configuración de inicio es esta:

OAuthOptions = new OAuthAuthorizationServerOptions() {
TokenEndpointPath = new PathString("/Token"),
Provider = new ApplicationOAuthProvider(PublicClientId),
AccessTokenExpireTimeSpan = SESSION_TIMEOUT,
AllowInsecureHttp = true
};

Y mi acción de cierre de sesión es simplemente esto:

public HttpResponseMessage Logout() {
var authentication = HttpContext.Current.GetOwinContext().Authentication;
authentication.SignOut(DefaultAuthenticationTypes.ExternalBearer);
return new HttpResponseMessage(HttpStatusCode.OK);
}

Dejé todo el material de autenticación por brevedad, pero para confirmar que estoy usando ExternalBearer al configurar el token.

En mi UI estoy almacenando el token en el almacenamiento local (aquí no se utilizan cookies, que es una decisión de diseño deliberada). Así que tengo un botón de cierre de sesión en mi IU, la acción Cerrar sesión se activa y el código funciona bien.

Sin embargo, si posteriormente presiono una acción en la API que requiere autorización, la solicitud aún se procesa (es decir, el usuario aún está autenticado, aunque debería haberse cerrado la sesión).

O me estoy perdiendo algo realmente obvio (no sería la primera vez ;-) o hay algo más fundamental pasando aquí - finalmente estoy haciendo ping a @leastprivilege ya que sé que esta es su área.

Cualquier ayuda o idea sería gratamente recibida.

Lo único que se me ocurre es que el token no tiene estado en el lado del servidor / API y, por lo tanto, no puede caducar o cerrar sesión.

Si ese es el caso, supongo que podría:

a) Agrega un token de actualización que crea un nuevo token que caduca en el pasado. ¿Funcionaría esto? - en realidad cancela eso, emitiría un nuevo token ... el anterior aún sería válido

b) Almacene el token de portador en la base de datos y compruebe cada vez, eliminando el token al cerrar la sesión (salado de forma natural, hash, etc.). Sin embargo, esto solo nos está devolviendo a tener un servidor con estado.

c) Puedo (y será) eliminar el token del almacenamiento local cuando alguien cierra sesión de forma explícita, sin embargo, el token sigue siendo técnicamente válido si un malintencionado puede interceptar el token. Naturalmente, todo lo anterior será sobre SSL de todos modos, lo que debería inhibir a los chicos / chicas malos .

d) Quizás esta es la razón por la cual muchas personas están almacenando el token de portador en una cookie (como mecanismo de almacenamiento), por lo que una vez que cierre sesión, al menos, la cookie se eliminará en la próxima actualización.

Lo siento, lo anterior es un poco como un despilfarro de cerebros, solo quiero anticiparme a cualquier pregunta

Answer 1

Como OAuth no es un protocolo de autenticación, no hay una noción de signout. Elimine el token de acceso en el cliente; eso es todo lo que puede hacer.

Si desea invalidar el token en el lado del servidor, agregue un ID único y haga un seguimiento de su servicio; deberá crear de forma manual algo así.

Answer 2

Esta pregunta ha estado aquí durante siglos (y respondida también), pero solo quería sonar en mis pensamientos.

Haría algo similar a su opción (C), pero usaría un vencimiento más corto en el token de acceso de portador de unos 10 o 20 minutos, de modo que cuando haya cerrado la sesión y eliminado el token en el cliente, aunque técnicamente el token siga siendo válido , el hombre malo solo tendrá el resto del tiempo de vencimiento para jugar con tu token válido.

En la práctica, usaría esto junto con un token de actualización de larga duración, de modo que pueda obtener un token de portador nuevo si caduca y quiero continuar interactuando con los recursos de API, sin tener que autenticar nuevamente.

Answer 3

Siempre que sepa que el token del portador vive en el lado del cliente, así que no creo que necesite una función de "cierre de sesión" del lado del servidor. Simplemente elimine el token del almacenamiento local del cliente, debe cerrar la sesión.

Answer 4

Tengo una hermosa solución aquí: http://www.nakov.com/blog/2014/12/22/webapi-owin-identity-custom-login-service/ . Es una implementación de sesión de usuario personalizada para la autorización de token de portador OAuth de API web basada en OWIN y la identidad estándar de ASP.NET (Microsoft.AspNet.Identity.EntityFramework). Funciona como la mayoría de la gente puede esperar:

• Las sesiones de API web mueren después de 30 minutos de inactividad.
• La vida de la sesión se amplía en cada solicitud HTTP autorizada con 30 minutos adicionales.
• El cierre de sesión funciona correctamente: después del cierre de sesión, el portador access_token deja de ser válido (se revoca).

El código fuente de trabajo completo está disponible en GitHub: https://github.com/SoftUni/SPA-with-AngularJS/tree/master/Ads-REST-Services