Si te encuentras con alguna parte que te causa duda puedes comentarlo y te ayudaremos tan rápido como podamos.
Solución:
Aquí hay información sobre la actualización del token de OAuth 2.0.
Caduca en definición
El estándar OAuth 2.0, RFC 6749, define el expires_in campo como el número de segundos hasta la expiración:
expires_in: RECOMENDADO. La vida útil en segundos del token de acceso. Por ejemplo, el valor “3600” indica que el token de acceso caducará en una hora desde el momento en que se generó la respuesta. Si se omite, el servidor de autorización DEBERÍA proporcionar el tiempo de vencimiento por otros medios o documentar el valor predeterminado.
Manejo de actualización de tokens: Método 1
Al recibir una válida access_token, expires_in valor, refresh_token, etc., los clientes pueden procesar esto almacenando un tiempo de vencimiento y verificándolo en cada solicitud. Esto se puede hacer usando los siguientes pasos:
- convertir
expires_ina un tiempo de caducidad (época, RFC-3339/ISO-8601 datetime, etc.) - almacenar el tiempo de caducidad
- en cada solicitud de recurso, verifique la hora actual contra la hora de vencimiento y realice una solicitud de actualización de token antes de la solicitud de recurso si el
access_tokenha expirado
Un ejemplo de implementación es el Go oauth2 biblioteca que convierte expires_in valor a una fecha y hora RFC 3339 en el token expiry propiedad. expiry no está definido por el estándar OAuth 2.0 pero es útil aquí.
Cuando verifique la hora, asegúrese de que sea la misma hora, por ejemplo, usando la misma zona horaria al convertir todas las horas a época o zona horaria UTC.
Además de recibir un nuevo access_tokenpuede recibir una nueva refresh_token con un tiempo de caducidad más lejano en el futuro. Si recibe esto, debe guardar el nuevo refresh_token para prolongar la vida de su sesión.
Manejo de actualización de tokens: Método 2
Otro método para manejar la actualización de tokens es actualizar manualmente después de recibir un error de autorización de token no válido. Esto se puede hacer con el enfoque anterior o solo.
Si intenta utilizar un access_token y obtiene un error de token no válido, debe realizar una actualización de token (si su token de actualización aún es válido). Dado que los diferentes servicios pueden usar diferentes códigos de error para los tokens caducados, puede realizar un seguimiento del código para cada servicio o una manera fácil de actualizar los tokens en todos los servicios es simplemente probar una sola actualización al encontrar un error 4xx.
Errores de token de acceso no válido
A continuación se muestran algunos códigos de error de servicios populares:
- Facebook: Error 467 Token de acceso no válido: el token de acceso ha caducado, se ha revocado o no es válido por algún otro motivo. Manejar tokens de acceso caducados.
- LinkedIn: Error 401 No autorizado.
- PayPal: Error 401 No autorizado.
Implementaciones
El servicio Zapier es un servicio que implementa la actualización después de un reintento de error de autorización.
Caducidad del token de actualización
Si tu refresh_token también ha caducado, deberá volver a realizar el proceso de autorización.
La especificación de OAuth 2.0 no define el vencimiento del token de actualización ni cómo manejarlo; sin embargo, varias API devolverán un refresh_token_expires_in propiedad cuando el token de actualización caduca. Las diferentes API manejarán la caducidad del token de actualización de manera diferente, por lo que es importante revisar los documentos por API, pero en general, puede recibir un nuevo token de actualización cuando actualice su token de acceso. La caducidad debe manejarse de manera similar, como convertir refresh_token_expires_in a una fecha y hora RFC 3339 refresh_token_expiry valor.
Algunos ejemplos incluyen LinkedIn, eBay y RingCentral. En la API de LinkedIn, cuando actualice los tokens de acceso, recibirá un token de actualización con una disminución refresh_token_expires_in propiedad dirigida al tiempo de caducidad del token de actualización original hasta que deba autenticarse nuevamente. La API de RingCentral devolverá tokens de actualización con un static tiempo para que el usuario no tenga que autenticarse nuevamente si las actualizaciones de token y las actualizaciones de token de actualización se realizan de manera consistente.
Recomendaría el Método 2 anterior, ya que un 401 puede ocurrir por múltiples razones, como la renovación de un certificado de firma de token o diferencias de reloj:
- Busque un 401 después de cada solicitud de API
- Obtenga un nuevo token, solo una vez
- Vuelva a intentar la solicitud de API, solo una vez
He implementado muchos clientes OAuth exitosos y siempre he usado esta técnica, y he evitado leer el campo expires_in en mi código del lado del cliente.
Aquí tienes las reseñas y puntuaciones
Si crees que ha sido de utilidad nuestro artículo, te agradeceríamos que lo compartas con otros juniors así nos ayudas a dar difusión a nuestro contenido.