Renovar el token de acceso para la concesión implícita de OAuth2

Question

Renovar el token de acceso para la concesión implícita de OAuth2

#1 de SilverlightFox (2 votos)
#2 de krotscheck (1 votos)

3

Queremos utilizar la Subvención implícita OAuth2 tal como se propone para aplicaciones de una sola página. Para aplicaciones de JavaScript que no tienen una sesión web clásica. Las aplicaciones solo tienen tokens de acceso que caducan después de una hora. Utilizamos un servicio de autenticación central (CAS) donde el usuario podría tener una sesión.

Al principio el usuario no tiene ninguna sesión. Cuando el usuario inicia la aplicación JS, navega el agente de usuario al CAS donde se autentica a través de sus credenciales. Después de la autenticación exitosa, será redirigido a la aplicación JS con el token de acceso en el fragmento.

Después de poco tiempo, el token de acceso ya no es válido y la aplicación necesita un token de acceso nuevo. Para eso la aplicación navega de nuevo el agente de usuario al CAS. Las preguntas son: ¿qué debería hacer el CAS?

El usuario ya tiene una sesión en el CAS. ¿Se permite usar esta sesión para autenticar al usuario? En este caso, el usuario no tiene que volver a proporcionar sus credenciales.
El servicio de autenticación central podría solicitar las credenciales del usuario nuevamente.

En mi opinión, pedirle al usuario sus credenciales una vez en una hora es algo extraño, así que preferiría la primera solución. ¿Pero sería una forma válida de obtener un nuevo token de acceso con respecto al RFC de OAuth2?

El RFC indica " The implicit grant [...] relies on the presence of the resource owner ". Creo que la primera solución no se basa en la presencia del propietario del recurso. Por ejemplo, el propietario del recurso podría dejar su computadora por algunas horas, pero la aplicación JS todavía está funcionando. Si un token de acceso deja de ser válido, la aplicación JS puede obtener un nuevo token de acceso simplemente navegando al CAS, que se autentica automáticamente a través de la sesión y se redirige a la aplicación JS. Esto se hace automáticamente sin la presencia del propietario del recurso.

El CAS solo podría estar seguro de que el propietario del recurso está presente si solicitaría las credenciales nuevamente. Pero eso significaría pedir las credenciales cada 30 minutos.

Si estas opciones no se aplican, ¿cómo se podría realizar el paso (B) en la Figura 4 en 4.2 del RFC6749 para renovar los tokens de acceso?

authentication oauth authorization session-management single-page-app

pregunta DanielE 09.08.2016 - 11:40

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication oauth authorization session-management single-page-app

Problemas de seguridad con la carga de una imagen Copia de seguridad de contraseña

score 2 · Answer 1

Si controla el CAS, entonces depende de usted cómo acceder a un nuevo token de acceso.

Dado que su usuario ya ha autorizado el SPA utilizando su CAS, si la sesión sigue siendo válida con el CAS, no es necesario pedirle que se vuelva a autenticar con sus credenciales.

Por supuesto, es hasta su nivel de riesgo aceptable por el tiempo que deben permanecer autenticados en el CAS. Si se trata de una aplicación de alta seguridad, es posible que desee reducir el tiempo de espera de la sesión o preguntarse por qué se ha establecido que la caducidad del token de acceso caduque antes del tiempo de espera de la sesión CAS.

Respuesta original:

~~Eche un vistazo a la sección Refresh Tokens .~~

La sesión que es válida en el CAS debe significar que el agente de usuario tiene un token de actualización válido: esto es lo que se necesita para renovar el token de acceso para el usuario.

Los tokens de actualización son credenciales que se usan para obtener tokens de acceso. Refrescar   Los tokens son emitidos al cliente por el servidor de autorización y son
  utilizado para obtener un nuevo token de acceso cuando el token de acceso actual
  se invalida o expira

Corrección: Los tokens de actualización no deben emitirse para subvenciones implícitas .

El servidor de autorización NO DEBE emitir un token de actualización.

La "presencia" del propietario del recurso solo se confía en la autorización inicial.

score 1 · Answer 2

Creo que la sección relevante de la especificación (sección 4.2.1) es la siguiente:

If the request is valid, the authorization server authenticates the
resource owner and obtains an authorization decision (by asking the
resource owner or by establishing approval via other means).

Para autenticar a un usuario, se le da la opción de "Preguntar al propietario del recurso" o "Establecer por otros medios". El primero generalmente significa credenciales de inicio de sesión. El último puede significar cualquier cosa, desde ssh auth, hasta cookies, para llamar al número de teléfono del usuario y pedirle que proporcione una muestra de impresión de voz cantando Barnes & Las "cabezas de pescado" de Barnes.

En resumen: el uso de la sesión en CAS es correcto y está dentro de las especificaciones.