rest - Navegador basado en OAuth/OpenID con inicio de sesión persistente

oauth-2.0 jwt

Question

Tenemos una aplicación web regular con autenticación basada en cookies y ahora queremos dividir frontend y backend (api) para tener una API pública de terceros. Entonces nuestro backend estará en un dominio y frontend en otro.

Para la autorización, nos gustaría cambiar para OAuth 2 con JWT . En este caso, nuestra aplicación de interfaz tendrá que usar access_token en lugar de la sesión de cookie y trae una vieja y vieja pregunta:

Cómo permanecer conectado - La infame casilla de verificación "Recordarme" (parte II de la autenticación basada en formularios para sitios web )

Desde el punto de vista de OAuth2 nuestra aplicación frontend va a usar algo entre la Subvención de Credenciales de Contraseña del Propietario de Recursos y la Subvención Implícita . Está más cerca de la Concesión de credenciales de contraseña, ya que seguiremos usando el formulario de inicio de sesión habitual y no redirigiremos al usuario a otro dominio para iniciar sesión. Al mismo tiempo, está más cerca de la concesión implícita, ya que todo será solo navegador. & JavaScript basado cuando access_token se guardará en el navegador.

El RFC dice que el servidor de autorizaciones NO DEBE emitir un token de actualización si usa Implicit Grant y mi pregunta es si aún es válido en este caso de uso cuando realmente no utiliza un OAduth de 3-D sino su propia API. Instintivamente, siento que tener refresh_token en el navegador es un agujero de seguridad y me gustaría confirmarlo con ustedes, pero esa refresh_token parece ser la única forma de que el inicio de sesión persistente funcione de la misma manera que con las cookies.

UPD después del comentario de @FlorentMorselli:

Las especificaciones de OpenID aún no responden a mi pregunta si puedo usar refresh_token con la aplicación de solo navegador

• Google dice que proporcionan refresh_token solo para access_type=offline
• OpenID Connect Core dice que no puede usar Refresh Token con flujo implícito
• OpenID Connect Core no dice nada sobre el uso de refresh_token con Hybrid Flow
• Solo hay un lugar donde dice algo prometedor sobre refresh_token con Hybrid Flow, pero nada preciso

UPD2 gracias a @reallifelolcat

Parece que OpenID Connect no admite explícitamente la Subvención de credenciales de contraseña del propietario del recurso , lo que significa que debe redirigir al usuario al servidor de OpenID Connect para realizar el inicio de sesión. ¿Sabes si hay otra forma de autenticarte con las credenciales del usuario sobre OAuth 2.0?

Creo que dividir api y frontend es cada vez más común y te agradecería si compartes cómo resuelves este problema de inicio de sesión persistente y si lo abandonas por completo y obligas al usuario a volver a iniciar sesión cada X semanas.

¡Gracias!

Answer 1

Los tokens de acceso y los tokens de actualización no tienen nada que ver con el inicio de sesión con OpenID Connect. Estos son solo para autorizar el acceso a la información de perfil de usuario y para las llamadas de servicio probablemente autenticadas a su API pública después del hecho de iniciar sesión. Consulte la especificación de la diferencia entre el token de identificación y el token de acceso.

Si vas a utilizar OpenID Connect para iniciar sesión, a partir de lo que has escrito hasta ahora, parece que necesitas alojar tu propio Proveedor de OpenID (OP) ya que quieres evitar ir a otro dominio para iniciar sesión:

seguiremos usando el formulario de inicio de sesión habitual y no redirigiremos al usuario a otro dominio para iniciar sesión.

Si quieres ser tu propio Proveedor de Identidad, entonces más poder para ti. Esto significa que tendrá que implementar su propia instancia de trabajo de un servidor de OpenID Connect, con autorizaciones y puntos finales de tokens.

Ahora esta es la parte donde entra su inicio de sesión persistente. La aplicación web de su navegador será una parte confiable del servidor OP que ahora tiene. Cuando un usuario intente iniciar sesión en la aplicación de su navegador utilizando OpenID Connect, deberá autenticarse en su servidor OP. Al pasar por el flujo de OIDC, su aplicación de navegador obtendrá un token de identificación que contiene un par emisor / sujeto que identifica al usuario.

Depende de usted determinar cómo el usuario permanece conectado a su servidor OP, pero siempre que el usuario al menos autorice la aplicación del navegador una vez: http://openid.net/specs/openid-connect-core-1_0.html# Consentir entonces puede guardar ese consentimiento para todas las solicitudes futuras de esta aplicación de navegador para iniciar sesión y, por lo tanto, mantener un inicio de sesión persistente.

Tendrás que considerar cómo manejarás la administración de sesiones, pero parece que ya tienes algo de cookies para que puedas usarlo (mira esta respuesta: Mecanismo de inicio de sesión de OpenID - Permanecer conectado ) De lo contrario, terminarás con una situación en la que la aplicación web de tu navegador tiene que obtener un nuevo token de identificación todo el tiempo.

Además, como mencionó Florent, hay consideraciones de seguridad que debe tener en cuenta al hacer un cliente público que sería su aplicación web basada en navegador. Ejemplo: https://tools.ietf.org/html/rfc6749#section-10.16