Actualmente estoy escribiendo un código para manejar oAuth (usando la API de Azure Graph, pero creo que las API de Google son similares).
Para realizar una llamada API necesito un token de acceso, que tiene una vida útil de aproximadamente una hora. Para obtener el token de acceso, primero necesito que el usuario autorice el uso de mi aplicación, lo que proporciona un código de autorización que tiene una vida útil de unos diez minutos. Al mismo tiempo que obtengo un token de acceso, también puedo obtener un token de actualización, que generalmente tiene una vida útil de 90 días. Sin embargo, puedo obtener un nuevo token de actualización antes de que caduque para asegurarme de conservar un token de actualización válido.
Entonces, hay tres tipos de códigos/tokens con los que lidiar.
¿Por qué se necesitan todos estos códigos y tokens diferentes? ¿Por qué no simplemente proporcionar un código de autorización con una vida útil de 90 días y terminar de una vez?
¿Estoy en lo cierto al suponer que si mi token de actualización caduca, entonces tengo que volver al principio de la cadena y solicitar acceso a mi usuario nuevamente?
Respuesta1
¿Por qué se necesitan todos estos códigos y tokens diferentes? ¿Por qué no simplemente proporcionar un código de autorización con una vida útil de 90 días y terminar de una vez?
El código de autorización es una de varias formas de entregar el token de acceso; no es un "paso" separado, pero sigue siendo parte del flujo inicial de "autenticación interactiva". Se diferencia del token de acceso real en que también necesita el secreto del cliente OAuth2 (o el desafío PKCE que se generó al principio) para utilizar el código. En teoría, esto significa que incluso si el código en sí es interceptado (por ejemplo, a través de redireccionamientos visibles en el lado del cliente), solo la aplicación original puede intercambiarlo por el token real.
Hay otros flujos que no utilizan uno: podría utilizar el flujo de "concesión implícita" para recibir directamente el token de acceso, por ejemplo, o podría utilizar un certificado para autenticar y recibir el token en un solo paso, dependiendo de cuál sea el protocolo OAuth. Apoyos para desplazados internos.
(Por ejemplo, las "cuentas de servicio" en Google se autentican utilizando un par de claves RSA para obtener un token de acceso; no utilizan el flujo de autenticación interactivo y, por lo tanto, no hay ningún código de autenticación).
¿Estoy en lo cierto al suponer que si mi token de actualización caduca, entonces tengo que volver al principio de la cadena y solicitar acceso a mi usuario nuevamente?
Sí, pero evitar eso es en realidad el propósito de un token de actualización en primer lugar.
Si solo tuviera un tipo de token (un token de acceso), cada vez que expirara tendría que volver al principio de la cadena. Esto generalmente se evita teniendo un token de actualización que normalmente tiene unmucho mas largovida útil, por ejemplo, si el token de acceso es válido durante varias horas o días, entonces es común que el token de actualización sea válido durante meses o años.
Yo diría que 90 días para un token de actualización es inusualmente corto y, en cierto modo, anula el objetivo de tener uno; supongo que Azure OAuth2 está configurado específicamente de esa manera para forzar la reautenticación a través de una credencial más difícil de robar, como como certificado de dispositivo o el esquema HMAC personalizado que utiliza "Windows Hello". (Por el contrario, los tokens de actualización emitidos por Google parecen no tener prácticamente ningún tiempo de caducidad; he estado usando el mismo token para acceder a Gmail IMAP durante años).
Respuesta2
Hay diferentes tipos porque sirven para diferentes propósitos. Una razón fácil por la que los tiene es porque podrían estar comprometidos y usarse para diferentes propósitos. Por lo tanto, que sean de corta duración garantiza que un manejo inadecuado o un cliente comprometido, si bien siguen siendo malos, podrían tener un impacto menor.
También ayuda separar qué hace qué. Una ficha significaría que solo tendrías que conseguir una ficha y poder hacer todo. Tener varios tokens hace que sea un poco más difícil tener la opción de hacer todo.
Verel RFC 6749para obtener más información sobre los tipos de tokens.