¿Por qué debería persistir los tokens de acceso OAuth 2 junto con el token de actualización?

Question

¿Por qué debería persistir los tokens de acceso OAuth 2 junto con el token de actualización?

#1 de Michael (6 votos)
#2 de Phil Ames (1 votos)

10

Eso es algo que encontré en un par de artículos sobre OAuth 2: cuando se trata de persistir tokens de actualización en la base de datos, algunos autores prefieren almacenar el token de acceso, o al menos mencionarlo como algo que debería hacer. Y cuando se trata de otorgar acceso basado en refresh_token , un ticket se recoge de la base de datos, se deserializa, se actualiza y se envía al usuario con un nuevo token de actualización.

Aquí hay un ejemplo de la tabla RefreshTokens , donde la columna ProtectedTicket se mantiene serializada access_tokens emitida al usuario:

Hasta ahora puedo pensar en al menos 3 razones en contra de este enfoque:

¿No es una amenaza para la seguridad cuando mantiene los tickets de acceso del usuario, solo espera que alguien los capture y los reutiliza para un servidor de recursos no sospechoso? El hash unidireccional no se puede utilizar, ya que necesitamos deserializar, actualizar y enviarlo al usuario, y no queremos mantener tokens de acceso válidos también.
Por ejemplo, desea actualizar la clave de cifrado utilizada para serializar / deserializar su boleto de vez en cuando, por si acaso. Si no desea que sus usuarios se desconecten una vez que caduque su access_token , debe preocuparse por actualizar esos tickets persistentes.
Tienes que escribir un trozo de código dependiendo de lo preocupado que estés por # 1 y # 2 . Tal vez incluso implementes algunos hacks sucios a tu alrededor del marco OAuth, ya que podría no proporcionar puntos de extensibilidad que necesitarás.

Entonces, la pregunta es, ¿por qué quieres hacer todo eso? ¿Qué tipo de ventaja debería dar para que realmente valga la pena? ¿No es más fácil , más seguro y más mantenible solo para crear un nuevo boleto una vez que hayas verificado refresh_token ?

authentication oauth key-management

pregunta 2ooom 29.10.2014 - 09:49

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication oauth key-management

¿Cuál es el modelo de amenaza para el cifrado de volúmenes AWS EBS? ¿Cómo puede WhatsApp recuperar los mensajes enviados a un teléfono dañado?

score 6 · Answer 1

¿Cuál sería el punto de hash de accessToken?

Hash contraseñas porque la gente las reutiliza en todas partes. Si no reutilizaran las contraseñas, no tendríamos que cifrarlas, la aplicación ha sido hackeada después de todo (ya que el atacante obtuvo acceso a la base de datos), por lo que todo está perdido.

accessTokens no se reutilizan . y agregando a la seguridad, solo se usan una vez (por ejemplo, durante 10 minutos, dependiendo de la vida útil del token). Entonces, ¿por qué necesitaríamos juntarlos? Los RefreshTokens se pueden usar para obtener múltiples accesstokens, por lo que parece razonable agruparlos, pero incluso eso es discutible ya que refreshTokens no se usa en todas las aplicaciones.

Si realmente lo desea, puede pensar en cifrar los accessTokens, pero suponemos que se ha pirateado toda su aplicación, incluida la clave de cifrado. Por cierto, en realidad no almacena un accessToken, sino que almacena el ticket para obtener un accessToken, pero eso no cambia la relevancia de su pregunta.

score 1 · Answer 2

Lo más probable es que la respuesta esté relacionada con el rendimiento.

Los tokens de acceso OAuth2 están diseñados para ser de corta duración, mientras que los tokens de actualización están diseñados para ser más duraderos, ya que pueden usarse para obtener nuevos tokens de acceso. La mayoría de las bibliotecas de clientes están diseñadas para almacenar en caché el token de acceso de OAuth para evitar golpear el servidor de autorización. Vea aquí:

enlace

/// <summary>
/// Default implementation is to try to refresh the access token if there is no access token or if we are 1 
/// minute away from expiration. If token server is unavailable, it will try to use the access token even if 
/// has expired. If successful, it will call <see cref="IAccessMethod.Intercept"/>.
/// </summary>
        public async Task InterceptAsync(HttpRequestMessage request, CancellationToken taskCancellationToken)
[...]

Si visita el área de juegos de Google OAuth2, puede ver algo de esto en acción: enlace

Cuando autoriza una API (simplemente intente escribir "perfil" para un ámbito personalizado y haga clic en 'Autorizar API' si no desea hacer clic en la lista), después de realizar el intercambio de autenticación y recibir un acceso / token de actualización, verás lo siguiente:

"El token de acceso caducará en [cuenta atrás] segundos.

[] Actualiza automáticamente el token antes de que caduque. "

Al almacenar en caché o almacenar el token de acceso, evita tener que realizar un viaje de ida y vuelta al servidor de autorización para intercambiar el token de actualización por un token de acceso (protegiéndose contra la latencia y las interrupciones del servidor de autorización). Algunos servidores también pueden limitar la frecuencia con la que puede intercambiar un token de actualización por un token de acceso (generar un token de acceso puede implicar una operación criptográfica "costosa" de su parte, por ejemplo).

Fugas en el token de acceso es "malo" en el sentido de que se puede usar sin ninguna otra información para afirmar la identidad de la persona que lo otorgó, pero se mitiga en parte por el hecho de que los tokens de acceso tienen una vida útil limitada. aumentando la presión sobre el atacante para que inmediatamente eche la mano / use los valores. Fugas en el token de actualización es (teóricamente) "peor", ya que permitiría un acceso perpetuo, sin embargo lo que hace que esto sea más complicado es que hacer una actualización < - > el intercambio de tokens de acceso también requiere el conocimiento de su OAuth2 client_secret.

En el modelo actual que usted describe, no está claro si ProtectedTicket está encriptado (usted menciona que está serializado, pero luego hablará sobre la actualización de tickets persistentes). Si está cifrando tokens de acceso en la base de datos para protegerlos del uso (mal) por parte de quienes tienen acceso a la base de datos administrativa, puede buscar soluciones para tratar con claves versionadas, lo que le permitiría rotar la clave de cifrado. Una con la que estoy familiarizado es enlace , y alguien ha creado enlaces .NET para esto (supongo que desde tu captura de pantalla eres en .NET).

KeyCzar puede proporcionar una forma sencilla de abordar algunas de sus inquietudes, pero muchas de las propiedades de seguridad reales de su sistema dependerán de su modelo de amenaza y muchos factores más allá del esquema de la base de datos.