OIDC Authorization Code Flow for Client Authentication in Couchbase Sync Gateway [Parte 3 de 3].

Couchbase Sync Gateway es compatible con Autenticación de clientes basada en OpenID Connect u OIDC.

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 frontales o móviles que accedan a Sync Gateway a través del punto final REST público.

En la primera entrada de esta serie, hablamos de los fundamentos de los flujos de autenticación y autorización OIDC y OAuth2 y en la entrada del blog de la semana pasada, aprendimos más a fondo sobre Autenticación de clientes de Sync Gateway basada en flujo implícito OIDC.

En este post, le presentaré Código de autorización OIDC basado en el flujo autenticación de cliente en el contexto de la replicación de Couchbase Sync Gateway.

Esta entrada asume familiaridad con los flujos OIDC y OAuth2 para autenticación y autorización. Si no está familiarizado con los flujos o necesita un repaso, consulte las entradas anteriores del blog enlazadas anteriormente.

Configuración de Couchbase Sync Gateway OIDC

En Pasarela de sincronización Couchbase debe estar configurado para la autenticación OIDC por base de datos.

A continuación se muestra una configuración básica de OIDC para Authorization Code. Consulta la documentación oficial de Couchbase para una lista completa de todas las opciones de configuración de OIDC.

• 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 o aplicación web. Tenga en cuenta que la client_id no corresponde al usuario final de la aplicación, que es técnicamente el propietario del recurso.
• clave_validación corresponde al secreto_cliente y debe generarse como parte del proceso de registro de la aplicación con el proveedor de OIDC.
• URL_de_retorno es la URL a la que se redirigirá en Sync Gateway después de que el cliente obtenga el token de identidad (ID token).
• regístrese en si se establece en verdaderose creará automáticamente el usuario en Sync Gateway una vez que se haya validado correctamente el token de identificación.
• nombre_usuario_reclamar corresponde a la reivindicación JWT que se utilizará como nombre de usuario de la puerta de enlace de sincronización. Por defecto, el nombre de usuario de Sync Gateway adoptaría la forma emisor+sujeto donde emisor se refiere al nombre de usuario prefijo. El valor del prefijo es, por defecto, el reclamo del emisor y puede configurarse para utilizar un valor de reclamo diferente a través de la opción prefijo_usuario opción de configuración.
• desactivar_sesiónsi se establece en verdaderopuede utilizarse para anular la creación automática de sesiones por parte de Sync Gateway tras una autenticación correcta.

Couchbase Sync Gateway Descubrimiento OIDC

Al iniciarse, Sync Gateway se conecta a el punto final de descubrimiento asociado con el proveedor/emisor de OIDC configurado para obtener los metadatos pertinentes del proveedor. La dirección los metadatos incluyen la información necesaria para la validación de los tokens 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. En caso necesario, puede anular la URL mediante Opción de configuración discovery_url de Sync Gateway.

Flujo de códigos de autorización OIDC para la autenticación de clientes

Este flujo se basa en el flujo de códigos de autorización OIDC estándar que se trata en el blog de conceptos básicos de la OIDC (primera parte de la serie).

Autenticación

1. Cuando un usuario inicia sesión en la aplicación cliente de Couchbase Lite, el cliente invoca el comando _oidc REST endpoint en Sync Gateway para iniciar el flujo de OIDC Auth Code.
2. Sync Gateway redirige la aplicación cliente a la URL del proveedor de OIDC.
3. El cliente inicia el flujo del código de autorización con el proveedor de OIDC para recuperar el código de autorización. Esto se realiza según los procedimientos de flujo estándar de OIDC descritos en el blog básico de la OIDC.
4. El cliente es redirigido a la pasarela de sincronización con el código de autorización. La URL de redirección corresponde a el punto final REST de devolución de llamada de OIDC.
5. La aplicación cliente invoca el punto final REST de devolución de llamada de OIDC con el código de autorización.
6. La pasarela de sincronización intercambia el código de la ficha de identificación, la ficha de actualización y la ficha de acceso enviando una solicitud adecuada al proveedor de OIDC. La solicitud incluye client_id y secreto_cliente que se configuraron en Sync Gateway. Esto permite al proveedor de OIDC validar que sólo los clientes de confianza puedan recuperar los tokens.
7. 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 papelespor lo que este registro automático funcionaría para usuarios públicos sin permisos de acceso específicos. Más adelante hablaremos de un flujo que describe cómo crear usuarios con permisos de acceso específicos.
   • Se crea una sesión para el usuario con un tiempo de espera de sesión inactiva de 24 horas. La sesión se crea SÓLO SI el desactivar_sesión es falso.
8. El identificador de sesión y los tokens de actualización se envían de vuelta a la aplicación cliente.
9. La aplicación cliente inicia una replicación estableciendo el identificador de sesión como cookie de sesión mediante la opción Autenticador de sesión.
10. 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.
11. 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, los documentos de ese canal no se replicarán.

Actualización de fichas

Una de las ventajas del flujo de código de autorización es que, además del token de identificación, también se devuelve a la aplicación cliente un token de actualización. La aplicación cliente puede utilizar el token de actualización para solicitar automáticamente un nuevo código de autorización sin necesidad de que el usuario final vuelva a autenticarse con sus credenciales de inicio de sesión.

1. Cuando la aplicación cliente desea actualizar el token, realiza una solicitud al punto final REST de actualización de OIDC con el token de actualización.
2. La Sync Gateway intercambia el token de actualización por el token de identificación y el token de acceso actualizados enviando una solicitud adecuada al proveedor de OIDC. La solicitud incluye client_id y secreto_cliente que se configuraron en Sync Gateway. Esto permite al proveedor de OIDC validar que sólo los clientes de confianza puedan recuperar los tokens.
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 del proveedor OIDC durante el inicio se utilizan para validar el token en "modo sin conexión".
   • Se crea una nueva sesión para el usuario con un tiempo de espera de sesión inactiva de 24 horas. La sesión se crea SÓLO SI el desactivar_sesión es falso.
4. El ID de sesión y los tokens de ID se envían de vuelta a la aplicación cliente.
5. La aplicación cliente inicia una replicación utilizando el ID de sesión como cookie de sesión siguiendo los mismos pasos que en el flujo anterior.

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 y 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 papel() API utilizando un documento de concesión de acceso que 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 has visto en los flujos anteriores, Couchbase 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.

Pero, ¿y si se desea 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 OIDC.
2. Tras el registro, el servidor de aplicaciones crea el usuario correspondiente en Sync Gateway a través de la función API REST para usuarios 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 de código de autorización descritos anteriormente.
4. Independientemente del tipo de flujo OIDC, una vez que la Sync Gateway valida el token de identificación, la 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 API REST para usuarios 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)

¿Qué es mejor: el flujo implícito o el flujo de código de autorización?

Desde mi punto de vista, no hay un flujo preferido. El flujo implícito es sencillo y, por lo general, es el preferido por la mayoría de nuestros usuarios. Dado que las aplicaciones móviles tienen un almacén seguro, el ID y los tokens de acceso pueden almacenarse de forma segura en el almacén de claves local del dispositivo. Puede obtener más información en esta entrada del blog sobre cómo aprovechar el flujo implícito de OIDC para la autenticación de Sync Gateway.

La ventaja del flujo de código de autorización es que proporciona una seguridad ligeramente superior. Esto se debe a que los tokens se conceden a la pasarela de sincronización a cambio del código de autorización sólo cuando al proveedor de OIDC se le presenta un código de autorización válido. client_id y secreto_cliente. Esto garantiza que sólo los clientes autenticados reciban los tokens. Además, los tokens de actualización permiten actualizar las sesiones de autenticación sin necesidad de que el usuario final introduzca sus credenciales cada vez.

Más recursos

En esta entrada describimos la compatibilidad con la autenticación OIDC en Sync Gateway. Estos son algunos recursos adicionales que quizás desee consultar:

• Tutorial: Autenticación OIDC utilizando el proveedor KeyCloak OIDC con Sync Gateway
• Documentación: Configuración OIDC de Sync Gateway
• 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.

Agradecimientos

Quiero dar las gracias al arquitecto de Sync Gateway Adam Fraser por su aportación a esta entrada del blog.
 

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