clientes exclusivos de keycloak: ¿por qué existen?

Estoy tratando de bearer-onlyentender el concepto de clientes en Keycloak.

Entiendo el concepto de público versus confidencial y el concepto de cuentas de servicio y grant_type=client_credentialsesas cosas. Pero con bearer-only, estoy atascado.

Buscar en Google solo revela fragmentos de discusiones que dicen:

No puede obtener un token de keycloak con un bearer-onlycliente.

Los documentos tampoco están claros. Todo lo que dicen es:

El tipo de acceso de solo portador significa que la aplicación solo permite solicitudes de token de portador.

Ok, si mi aplicación solo permite solicitudes de token de portador, ¿cómo obtengo este token si no puedo obtenerlo de Keycloak usando la identificación / secreto del cliente?

Y si no puedes obtener una ficha, ¿qué puedes hacer? ¿Por qué existen estos clientes? ¿Alguien puede dar un ejemplo del uso de este tipo de cliente?

keycloak

— kurtgn
fuente

Respuestas:

Según tengo entendido, se usa cuando tienes algún servicio interno. Digamos que tienes ServiceAy ServiceB. Un usuario llama ServiceAque en la mano llama ServiceB. ServiceBnunca es llamado por el usuario directamente, solo por otros servicios. ServiceAobtendrá un token utilizando las credenciales del usuario. Y luego usará este token para llamar ServiceB. ServiceBnunca iniciará un inicio de sesión. Solo usará el token para verificar los permisos.

En este caso, ServiceA será confidentialy ServiceB serán bearer-onlyclientes.

— Yuriy P
fuente

Esto significa que si mi cliente es solo portador, la única opción disponible para mí es hacer solicitudes de verificación a Keycloak para asegurarme de que el token ServiceAsea válido. ¿Derecha? Pero si este es el caso, ¿por qué llamar a Keycloak? Si mi cliente tiene una clave pública de Keycloak, puede verificarla utilizando esta clave sin tener que llamar a Keycloak.

— kurtgn

Debido al alcance del token. El servicio A debe tener un alcance diferente al servicio B, por lo que necesita Keycload para el intercambio de tokens

— Julian Egner el

@JulianEgner Esto tiene sentido, excepto que Token Exchange se encuentra actualmente en Tech Preview, no es totalmente compatible y debe activarse explícitamente con una Variable Env. ¿Está bearer-onlyrealmente en su lugar solo para apoyar este caso de uso que aún no está listo?

— irbull

@irbull ¿de dónde sacaste la información de que el intercambio de tokens estaría en la vista previa de tecnología?

— Julian Egner

@JulianEgner Estaba en la parte inferior de sus documentos. Enumerado en keycloak.org/docs/latest/securing_apps/… dice "Token Exchange es Technology Preview y no es totalmente compatible. Esta función está deshabilitada de manera predeterminada".

— irbull

Significado del tipo de acceso solo al portador

El tipo de acceso de solo portador significa que la aplicación solo permite solicitudes de token de portador. Si está activado, esta aplicación no puede participar en los inicios de sesión del navegador.

Entonces, si selecciona su cliente como bearer-onlyentonces, en ese caso, el adaptador keycloak no intentará autenticar a los usuarios, sino solo verificar los tokens de portador. Es por eso que la documentación de keycloak también mencionó que la bearer-onlyaplicación no permitirá el inicio de sesión desde el navegador.

Y si no puedes obtener una ficha, ¿qué puedes hacer? ¿Por qué existen estos clientes?

Su cliente no puede configurarse como solo portador en Keycloak Server. Sin embargo, todavía puede usar solo portador en la configuración del adaptador. Keycloak no permite que los clientes "solo portadores" (al configurar su cliente en el servidor) obtengan tokens del servidor. Intente cambiar su cliente a "confidencial" en el servidor y configure solo el portador en la configuración de su adaptador (keycloak.json).

Entonces, si comprende la declaración anterior, si tiene dos microservicios que están hablando entre sí en el caso, la persona que llama será confidentialy la persona que llamará serábearer-only

Y Keycloak también mencionó

Los clientes que solo son portadores son servicios web que nunca inician un inicio de sesión. Por lo general, se utilizan para asegurar el back-end.

Entonces, si desea usar cualquier adaptador que pueda usar, bearer-onlydependerá de la necesidad

— Subodh Joshi
fuente

gracias Subodh por tu explicación! Esto significa que si mi cliente es solo portador, la única opción disponible para mí es hacer solicitudes de verificación a Keycloak para asegurarse de que el token sea válido. ¿Derecha? Pero si este es el caso, ¿por qué llamar a Keycloak? Si mi cliente tiene una clave pública de Keycloak, puede verificarla utilizando esta clave sin tener que llamar a Keycloak.

— kurtgn

@kurtgn Si está utilizando algún adaptador, solo sugeriré usar el que de lo bearer-onlycontrario haga su clienteconfidential

— Subodh Joshi

No, no estoy usando adaptadores, estoy codificando en Python, no hay adaptadores específicos de Python para Keycloak, así que tengo que usar librerías genéricas OIDC

— kurtgn

¿Qué biblioteca está utilizando con Keycloak + Python Integration?

— Subodh Joshi

Este docs.authlib.org/en/stable/client/django.html

— kurtgn

Respuesta corta: no puede obtener un token de acceso usando un cliente solo de portador, pero puede obtener un token de acceso que un cliente solo de portador puede aceptar usando otro cliente.

Más detalles Los clientes solo portadores representan de manera útil las aplicaciones de back-end, como el servicio web, llamado por la aplicación frontal y protegido por el servidor de autorización (= keycloak)

El usuario no llama directamente a la aplicación de servicios web / backend, por lo que no se puede reproducir en el flujo interactivo de usuario Oauth2.0. La configuración de "solo portador" documenta este hecho en el servidor keycloak, lo que permite al administrador configurar el cliente sin valores obligatorios (por ejemplo, redirigir uri ...) y permitir mensajes de error útiles si alguien intenta obtener un token para dicho cliente

Sin embargo, esto no significa que no pueda configurar roles específicos para este cliente: por lo tanto, debe aparecer en el reino de keycloak.

Además, el cliente de solo portador debe verificar el token de acceso recibido, especialmente, si esta característica (recomendada) del adaptador "verificar-token-audiencia" está activada, el cliente de solo portador debe verificar que se haya emitido el token de acceso para ello: el cliente de solo portador debe estar en el atributo de audiencia del token de acceso: consulte https://www.keycloak.org/docs/latest/server_admin/index.html#_audience

Para la gestión de audiencias por keycloak, los clientes de solo portador deben estar registrados en el reino de keycloak.

— Thomas LIMIN
fuente