Flujo implícito OIDC para autenticación de clientes en Couchbase Sync Gateway [Parte 2 de 3].

OpenID Connect (OIDC) es un popular mecanismo de autenticación de clientes soportado por Couchbase Sync Gateway.

En este contexto, clientes pueden ser clientes de Couchbase Lite que sincronizan datos con Sync Gateway a través de Internet utilizando el protocolo de replicación basado en websockets o pueden ser aplicaciones web frontend o móviles acceso a Sync Gateway a través del punto final REST público.

La semana pasada, discutimos los fundamentos de los flujos OIDC y OAuth2. En la entrada de blog de esta semana, le presentaré la autenticación de cliente basada en flujo implícito de OIDC en el contexto de Pasarela de sincronización Couchbase replicación. Este post asume familiaridad con OIDC y OAuth2 para autenticación y autorización. Así que si no estás familiarizado con los flujos o necesitas un repaso, ponte al día con la entrada del blog de la semana pasada.

Configuración de Couchbase Sync Gateway OIDC

Por base de datos, Couchbase Sync Gateway debe estar configurado para autenticación OIDC.

He aquí un ejemplo básico config para el flujo implícito. (Consulte las páginas de documentación oficial de una lista completa de todas las opciones de configuración.)

• • emisor es la URL de autenticación correspondiente al proveedor de identidad OIDC
  • client_id se genera como parte del proceso de registro de la aplicación con el proveedor de OIDC. En este caso, el cliente se refiere al Couchbase Lite app o web app. Tenga en cuenta que client_id no corresponde al usuario final de la aplicación, que es técnicamente el "Propietario del recurso".
  • En regístrese en si se establece en verdaderose creará automáticamente el usuario en la puerta de enlace de sincronización una vez que se haya validado correctamente el token de identificación.
  • nombre_usuario_reclamar corresponde al Reclamación JWT que se utilizará como nombre de usuario de Sync Gateway. Por defecto, el nombre de usuario de Sync Gateway adoptaría la forma emisor+sujeto donde emisor se refiere al nombre de usuario prefijo. En prefijo por defecto es el valor emisor reclamación y puede ser configurado para utilizar un valor de reclamación diferente a través de la opción de configuración user_prefix.

Couchbase Sync Gateway Descubrimiento OIDC

Al iniciarse, la puerta de enlace de sincronización se conecta al punto final de descubrimiento asociado con el proveedor/emisor de OIDC configurado para obtener los metadatos pertinentes del proveedor. La dirección metadatos incluye la información pertinente necesaria para la validación del token, como las claves públicas del emisor, los algoritmos de cifrado admitidos utilizados para codificar las declaraciones en el token de identificación, etc.

El punto final de descubrimiento corresponde a una URL de descubrimiento bien conocida asociada al emisor. Si es necesario, se puede anular mediante el parámetro Opción de configuración discovery_url de Sync Gateway.

Flujo implícito OIDC para la autenticación de clientes

Este flujo se basa en el flujo implícito estándar OIDC tratado en el blog OIDC basics. Es más sencillo que el método alternativo basado en el flujo de códigos de autorización y, por lo general, es el método preferido para la autenticación de clientes OIDC de Sync Gateway.

Flujo implícito mediante token portador

En este flujo, los clientes de Couchbase Lite incrustan el ID Token recuperado del Proveedor OIDC (OP) como la ficha del portador dentro de la cabecera de autorización durante la inicialización de la replicación.

1. Cuando un usuario inicia sesión en la aplicación cliente de Couchbase Lite, el cliente inicia un flujo implícito OIDC con el proveedor OIDC para recuperar el token de ID. Esto es por procedimientos estándar de flujo OIDC esbozado en el blog OIDC basics.
2. La aplicación cliente inicia una replicación utilizando el token de ID como token de portador en el encabezado de autorización HTTP.
3. Sync Gateway valida el token de identificación localmente. Una vez validado el token, se genera un UsuarioCtx se crea el objeto.
   • Los metadatos recuperados de la URL de descubrimiento de proveedores de OIDC durante el inicio se utilizan para validar el token en "modo sin conexión".
   • Si es la primera vez que el usuario se autentica con Sync Gateway y no existe un usuario correspondiente en el servidor, Sync Gateway crea automáticamente un usuario si la opción de configuración "registrar" está establecida en true.
     • Nota: El usuario que se crea no está asociado a ninguna concesión de acceso, como por ejemplo canales o papeles. Este registro automático sólo funcionaría para usuarios públicos sin derechos de acceso específicos. Más adelante hablaremos de un flujo que describe cómo crear usuarios con derechos de acceso específicos.
4. Tras una inicialización correcta, la replicación procede como de costumbre y se sincronizan los cambios de documentos en la aplicación cliente y en Sync Gateway.
   • Si el usuario se elimina durante una replicación activa, la replicación finaliza.
   • Si las concesiones de acceso asociadas al usuario han cambiado, los documentos afectados por las concesiones de acceso actualizadas no se replicarán. Por ejemplo, si un usuario pierde el acceso a un canal, no se extraerán los documentos de ese canal.

Flujo implícito utilizando el identificador de sesión

En este flujo, los clientes de Couchbase Lite incrustan el ID de sesión generado por el Sync Gateway tras la validación exitosa del ID Token como una cookie de sesión durante la inicialización de la replicación.

1. Cuando un usuario inicia sesión en la aplicación cliente de Couchbase Lite, el cliente inicia el flujo implícito de OIDC con el proveedor de OIDC para recuperar el token de ID. Esto es por estándar Procedimientos de flujo de OIDC descritos en el blog Conceptos básicos de OIDC.
2. La aplicación cliente crea una sesión utilizando el punto final REST de sesión. El token de ID se establece como token de portador en el encabezado de autorización HTTP.
3. Sync Gateway valida el token de identificación localmente. Una vez validado el token, se genera un UsuarioCtx se crea el objeto.
   • Los metadatos recuperados de la URL de descubrimiento de proveedores de OIDC durante el inicio se utilizan para validar el token en "modo sin conexión".
   • Si es la primera vez que el usuario se autentica con Sync Gateway y no existe un usuario correspondiente en el servidor, Sync Gateway creará automáticamente un usuario si el campo regístrese en está configurada como verdadero.
     • Nota: El usuario que se crea no está asociado a ninguna concesión de acceso, como por ejemplo canales o papeles. Este registro automático funcionaría para usuarios públicos sin derechos de acceso específicos. Más adelante hablaremos de un flujo que describe cómo crear usuarios con derechos de acceso específicos.
   • Se crea una sesión para el usuario con un tiempo de espera de sesión inactiva de 24 horas.
     • Nota: La caducidad de la sesión no está relacionada con la caducidad del identificador. Más información sobre la caducidad de la sesión en la sección de preguntas frecuentes.
4. El ID de sesión se devuelve al cliente.
5. La aplicación cliente inicia una replicación estableciendo el ID de sesión como cookie de sesión mediante la función Autenticador de sesión como discutido en los documentos.
6. Sync Gateway comprueba la validez de la sesión para determinar si se ha eliminado o ha caducado.
   • Si la sesión está activa, la sesión se amplía automáticamente a 24 horas si han transcurrido 10% de tiempo de espera de sesión inactiva.
7. Tras una inicialización correcta, la replicación se realiza de la forma habitual y se sincronizan los cambios en los documentos de la aplicación cliente y de Sync Gateway.
   • Si el usuario se elimina durante una replicación activa, la replicación finaliza.
   • Si las concesiones de acceso asociadas al usuario han cambiado, los documentos afectados por las concesiones de acceso actualizadas no se replicarán. Por ejemplo, si un usuario pierde el acceso a un canal, los documentos de ese canal no se extraerán.

Asociar concesiones de acceso a usuarios autenticados

Pasarela de sincronización canales y papeles son dos elementos clave del mecanismo de control de acceso de Sync Gateway. Definen el subvenciones de acceso asociada a un usuario, que dicta el conjunto de documentos a los que el usuario tiene acceso de lectura/escritura.

Hay un par de opciones para asignar concesiones de acceso a un usuario:

• • Asignación dinámica de usuarios a canales o roles mediante la función de sincronización con el acceso() o API role() utilizando un documento de concesión de acceso. Un documento de concesión de acceso especifica los canales o roles a los que debe asignarse un usuario.
  • Asignación estática de subvenciones a los usuarios a través del administrador API REST para usuarios.

Como ha visto en los flujos de autenticación de OIDC anteriores, Sync Gateway puede configurarse para crear automáticamente el usuario autenticado en Sync Gateway tras una autenticación correcta. Sin embargo, el usuario creado no está asociado a ninguna concesión de acceso. Esto funciona para un usuario público con acceso a un canal público.

¿Y si quieres asignar derechos de acceso específicos a un usuario?

Esta tarea suele gestionarse a través de un servidor de aplicaciones backend que se encargaría de crear o actualizar el usuario. Sync Gateway sólo es responsable de la autenticación OIDC.

He aquí un flujo típico:

1. Un proceso backend o servidor de aplicaciones se encarga de registrar a los usuarios en el proveedor de OIDC.
2. Tras el registro, el servidor de aplicaciones crea el usuario correspondiente en Sync Gateway a través de la función Usuario REST API o añadiendo un documento de concesión de acceso adecuado.
3. La próxima vez que el usuario inicie sesión en la aplicación, la autenticación OIDC procederá utilizando los procedimientos de flujo implícito descritos anteriormente.
4. Independientemente del tipo de flujo OIDC, una vez validado el token de identificación, Sync Gateway no crea un usuario porque ya existe.
5. La replicación procede como de costumbre utilizando el usuario autenticado.
6. Si se actualiza un usuario en el proveedor de OIDC, el servidor de aplicaciones actualiza el usuario correspondiente en la pasarela de sincronización a través de la función Usuario REST API o actualizando el documento de concesión de acceso.
   • Si se elimina un usuario durante una replicación activa, la replicación finaliza.
   • Si las concesiones de acceso asociadas al usuario han cambiado, los documentos afectados por las concesiones de acceso actualizadas no se replicarán. Por ejemplo, si un usuario pierde el acceso a un canal, los documentos de ese canal no se extraerán.

Preguntas más frecuentes (FAQ)

¿Cómo se gestiona la caducidad de los tokens de identificación con la replicación?

La validación del token de identificación se realiza en el momento de la autenticación cuando se inicia una replicación. Un token que caduque durante una replicación activa no afectará a la replicación en curso. Sin embargo, si el usuario asociado a la réplica es eliminado, la réplica finalizará. Del mismo modo, si se producen cambios en las concesiones de acceso asociadas al usuario, éstos surtirán efecto inmediatamente en la réplica en curso.

¿La expiración de la sesión pondría fin a una replicación continua?

No. La validación de la sesión se realiza en el momento de la autenticación cuando se inicia una replicación. Si una sesión caduca durante una replicación activa, no afectará a la replicación en curso. Sin embargo, si el usuario asociado a la réplica se elimina, la réplica finalizará. Del mismo modo, si se producen cambios en las concesiones de acceso asociadas al usuario, éstos surtirán efecto inmediatamente en la réplica en curso.

¿Si se borran las sesiones antes de que caduquen, finalizará la replicación?

No. La validación de la sesión sólo se realiza en el momento de la autenticación, cuando se inicia una replicación. Por lo tanto, si una sesión caduca durante una replicación activa, esto no afectará a la replicación en curso. Sin embargo, si el usuario asociado a la réplica se elimina, la réplica finalizará. Del mismo modo, si se producen cambios en las concesiones de acceso asociadas al usuario, éstos surtirán efecto inmediatamente en la réplica en curso.

¿Es posible utilizar reclamaciones JWT para asignar concesiones de canal?

Eso no es posible en este momento.

¿A qué proveedores de OIDC apoya?

Apoyamos a cualquier proveedor que cumpla con OIDC y Token web JSON (JWT) normas.

Más recursos

En este post, describimos el soporte de autenticación OpenID Connect (OIDC) en Couchbase Sync Gateway. En un próximo post, discutiremos la implementación de Authorization Code Flow con Sync Gateway.

He aquí algunos recursos adicionales:

• • Tutorial: Autenticación OIDC utilizando el proveedor KeyCloak OIDC con Sync Gateway
  • Configuración de la pasarela de sincronización OIDC
  • Documentación: Autenticación de clientes de Sync Gateway

Si tiene alguna pregunta o sugerencia, deje un comentario a continuación o envíeme un correo electrónico a priya.rajagopal@couchbase.com. En Foros de Couchbase son otro buen lugar al que dirigirse con preguntas.

Póngase al día con el resto de entradas de esta serie sobre autenticación y autorización:

• • Fundamentos de OAuth 2.0 y OIDC para autenticación y autorización [Parte 1].
  • Flujo implícito OIDC para autenticación de clientes en Couchbase Sync Gateway [Parte 2]
  • Flujo de código de autorización OIDC para autenticación de cliente en Couchbase Sync Gateway [Parte 3]