¿Debemos almacenar accesstoken en nuestra base de datos para oauth2?

Técnicamente, puede almacenar el token de acceso en su base de datos y usarlo para llamadas a la API hasta que caduque. Sin embargo, podría ser más problemático de lo que vale.

En primer lugar, como señala Jonathan en su comentario anterior, ahora tiene que preocuparse por proteger su base de datos y los datos que contiene. Estos tokens le dan acceso a información bastante privilegiada sobre sus usuarios. Por supuesto, simplemente almacenar el token en la sesión de almacenamiento también podría ponerlo en el disco, dependiendo de la configuración de su sesión. Es una buena idea mantenerlo encriptado mientras no lo esté utilizando.

Su escenario propuesto sobre el usuario que borra las cookies y regresa también es un problema. Puede tomar el token de acceso de la base de datos y pegarlo nuevamente en sus cookies, pero antes de hacerlo, debe asegurarse de que sean quienes dicen que son, y ahora tiene que hacer otra capa de contraseñas solo para darles acceso a la ficha que ya te dieron.

Probablemente esté mejor re-haciendo el flujo de autorización cuando regresen y haga clic nuevamente en el botón de inicio de sesión. No es que caro. Pero si eso es realmente un showstopper para ti, entonces almacenar el token es una opción. Solo tendrás que tener mucho cuidado al resolver todos los problemas asociados.

He estado pensando en esto y es posible que haya encontrado una respuesta que funcione para nosotros, aunque no puedo decir si funcionaría para ti.

En nuestro entorno, la razón principal por la que podríamos necesitar usar tokens de acceso es para operar en nombre de un usuario después de que se complete algún proceso automatizado o de back-end, o de manera programada. En tal caso, no podemos simplemente pedirle al usuario que vuelva a iniciar sesión porque el usuario no está involucrado directamente en este flujo de trabajo (habría solicitado que se realizara el trabajo pero no está ahí cuando se complete). Así que tenemos que tener acceso al token de acceso de alguna manera.

Por supuesto, me gustaría omitir la reautorización cuando sea posible también, si no causa problemas.

Pero tampoco me gusta la idea de almacenar todo lo necesario para usar el token de acceso en el servidor web. Por lo tanto, incluso si cifro el token de acceso en la base de datos, realmente no mitiga mis temores si la clave de cifrado se almacena en el servidor web. Heck, el secreto del cliente y la ID de la aplicación también están ahí, así que eso es todo.

Así que aquí está mi solución propuesta, que requiere cuatro actores:

El servidor web almacena la cadena de conexión appid, secreta y de base de datos (por supuesto). Cuando obtiene un token de aplicación, genera una clave de cifrado simétrica aleatoria y encripta el token de acceso. La base de datos obtiene el token de acceso cifrado y la clave de cifrado se almacena en una cookie de cliente . Al mismo tiempo, el servidor web envía la clave de cifrado y la ID de usuario al sistema backend como un par.

Cuando el cliente está utilizando el sitio, se puede evitar la reautenticación utilizando la cookie del cliente para descifrar el token de acceso en la base de datos; Si la cookie desaparece, la reautenticación tiene que suceder, pase lo que pase. El sistema backend (que tendría una superficie de ataque mucho más pequeña que el servidor web) también tiene una cadena de conexión DB, por lo que es el único lugar donde residiría toda la información necesaria para interactuar con la información del usuario; podría usar la información a voluntad durante la vida útil del token de acceso.

Esto deja al servidor web solo con acceso transitorio a cualquier token de acceso, y el token nunca se almacena en el cliente. Me parece bastante seguro, aunque tal vez algunos dirían que está sobre diseñado. ¿Pensamientos?

Creo que hay cierta confusión sobre el token de acceso y cómo se usa, lo que puede causar un problema de seguridad.

Es correcto que los tokens pueden ser un riesgo de seguridad, pero esto depende de la información que solicite del servicio. Una lista de amigos es más información que el nombre y el apellido, por ejemplo, pero esa información no es tan vital como la información personal. En cualquier caso, NUNCA desea exponer el token de acceso real, ya que es como exponer una contraseña a su aplicación.

Elijo hacer un 'token' secundario, si así lo desea, que contenga un valor de sesión (por ejemplo, un valor de sesión cifrado en cookies) que identifique al usuario hasta que caduque. Así que tengo el token de acceso en la base de datos (probablemente debería estar cifrado, solo para estar seguro) que pueda acceder a la información del usuario.

También puede recuperar el ID de la persona a través del token. Si al menos almacena esto en la base de datos, puede hacer coincidir el token recuperado a través del ID de la persona. De esa manera, cuando intercambies un código por el token de acceso, puedes comparar las ID y encontrar el registro correcto.

Recomendaría almacenar tokens si alguna vez alcanzas tu límite máximo de tokens en la aplicación que estás utilizando. Sin embargo, en lugar de la base de datos, sugeriría usar Redis. Si se pierde un token, la aplicación debe configurarse para que se siga ejecutando, de modo que no necesite persistir a largo plazo, Redis es mucho más rápido que usar la base de datos y también existen algunas implementaciones de Redis realmente simples que no deberían llevar mucho tiempo. Levántate y corre.