OdooWiki OCA HUB
Sin categoría Licencia: LGPL-3

Autenticación con token bearer JWT.

Traducción automática al español (DeepSeek) de la descripción original de OCA, que está en inglés.

auto_awesome Qué hace este módulo

Generado por IA a partir del código · Odoo 18.0

Permite a Odoo aceptar tokens JWT bearer (o una cookie segura) como método de inicio de sesión para rutas de API/web, configurado mediante registros JWT Validator. Los administradores definen validadores que comprueban la firma, la audiencia y el emisor del token, y luego asignan el token a un usuario de Odoo.

Este módulo añade una nueva pantalla de configuración llamada JWT Validators, que se encuentra en el menú Users y solo es visible para los administradores técnicos. Cada registro describe cómo deben considerarse fiables los tokens JWT entrantes.

  • Se elige el tipo de firma: un secreto compartido (HS256/HS384/HS512) o una clave pública obtenida de un JWK URI (algoritmos ES, RS, PS).
  • Se establecen la audiencia y el emisor esperados, que son obligatorios y se verifican en cada token.
  • Se decide qué usuario de Odoo representa el token (actualmente un usuario estático) y, opcionalmente, se empareja un partner a partir de la claim email del token, con una opción para rechazar tokens cuando no se encuentra ningún partner.
  • Se pueden encadenar validadores: si uno falla, se prueba el siguiente.
  • Se puede activar el modo cookie, que almacena el token en una cookie HttpOnly con nombre, ruta, duración y flag secure configurables.

El módulo también cambia cómo autentica Odoo las peticiones web: las rutas pueden usar los métodos de autenticación jwt, public_or_jwt y variantes con nombre. Comprueba la cabecera Authorization o la cookie, valida el token e inicia la sesión del usuario sin sesión. Se añaden varias protecciones: los nombres de los validadores deben ser únicos y identificadores de Python válidos, las cadenas de validadores no pueden formar bucles y se requiere un nombre de cookie cuando el modo cookie está activado. Solo los administradores del sistema pueden gestionar estos registros.

Menús que añade

JWT Validators
Modelos y campos (2)
  • ir.http · amplía un modelo existente
  • auth.jwt.validator · modelo nuevoname, issuer, audience, secret_key, cookie_name, cookie_path, cookie_secure, cookie_enabled, cookie_max_age, signature_type, static_user_id, secret_algorithm, user_id_strategy, next_validator_id, public_key_jwk_uri, partner_id_required, partner_id_strategy, public_key_algorithm

Texto generado por IA (DeepSeek) al leer el código de la versión 18.0 en GitHub; puede contener errores, así que verifícalo en el código antes de decidir. Ver el código en GitHub

Disponibilidad por versión

Revisado: 2026-11-03
Confirmado (verificado en repositorio y rama) Estimado (sin verificar) Sin información

Estado de confirmación: 5 confirmadas, 4 sin información de 9 versiones.

Fuentes · Odoo 14.0

Confirmado el 2026-11-03 en la rama 14.0 de OCA/server-auth.

terminal Instalación y uso

Documentación de OCA · Odoo 18.0

Este módulo requiere que esté instalada la librería pyjwt.

Este módulo permite a los desarrolladores añadir un nuevo método de autenticación jwt en las rutas de los controladores de Odoo.

Para usarlo, debe:

  • Crear un registro auth.jwt.validator para configurar cómo se validará el token JWT.
  • Añadir un atributo auth="jwt_{validator-name}" o auth="public_or_jwt_{validator-name}" a las rutas que desea proteger, donde {validator-name} corresponde al atributo name del registro del validador JWT.

El módulo auth_jwt_demo proporciona ejemplos.

El validador JWT se puede configurar con las siguientes propiedades:

  • name: el nombre del validador, para que coincida con la propiedad de ruta auth="jwt_{validator-name}".
  • audience: una lista separada por comas de audiencias permitidas, utilizada para validar la reclamación aud.
  • issuer: se utiliza para validar la reclamación iss.
  • El tipo de firma (secreto o clave pública), el algoritmo, el secreto y el JWK URI se utilizan para validar la firma del token.

Además, se valida la reclamación exp para rechazar los tokens caducados.

Si falta la cabecera HTTP Authorization, está mal formada o contiene un token no válido, la solicitud se rechaza con un código 401 (Unauthorized), a menos que el modo cookie esté habilitado (véase más abajo).

Si el token es válido, la solicitud se ejecuta con el id de usuario configurado. Por defecto, la estrategia de selección del id de usuario es static (es decir, la misma para todas las solicitudes) y el usuario seleccionado se configura en el validador JWT. Se pueden proporcionar estrategias adicionales sobrescribiendo el método _get_uid() y ampliando el campo de selección user_id_strategy.

El usuario seleccionado no se almacena en la sesión. Solo está disponible en request.uid (y, por tanto, es el que se utiliza en request.env). Para evitar cualquier confusión y desajuste entre el bearer token y la sesión, este módulo rechaza las solicitudes realizadas con una sesión de usuario autenticado.

Además, si se configura un partner_id_strategy, se busca un partner y, si se encuentra, su id se almacena en el atributo request.jwt_partner_id. Si partner_id_required está establecido, se devuelve un 401 (Unauthorized) si no se encontró ningún partner. De lo contrario, request.jwt_partner_id queda como falsy. Se pueden proporcionar estrategias adicionales sobrescribiendo el método _get_partner_id() y ampliando el campo de selección partner_id_strategy.

El payload JWT decodificado se almacena en request.jwt_payload.

El método public_auth_jwt delega la autenticación al método estándar public de Odoo cuando la cabecera Authorization no está establecida. Si está establecida, se realiza la autenticación JWT normal tal como se describe arriba. Este método es útil para endpoints públicos que necesitan funcionar para usuarios anónimos, pero que pueden mejorarse cuando se conoce un usuario autenticado. Un caso de uso típico es un endpoint de "add to cart" que puede funcionar para usuarios anónimos, pero que puede mejorarse vinculando el carrito a un cliente conocido cuando se conoce el usuario autenticado.

Puede habilitar un modo cookie en los validadores JWT. En este caso, el payload JWT obtenido de la cabecera Authorization se devuelve como una cookie Http-Only. Este modo es a veces más sencillo para aplicaciones front-end que entonces no necesitan almacenar y proteger el token JWT entre solicitudes y pueden simplemente confiar en los mecanismos de gestión de cookies de los navegadores. Cuando se proporcionan tanto la cabecera Authorization como una cookie, la cookie se ignora para permitir que los clientes se autentiquen con un usuario diferente proporcionando un nuevo token JWT.

Traducción automática al español (DeepSeek) de la documentación original de OCA; los comandos y el código no se traducen. Sin información verificada en OCA: Configuración.

info

Datos importados de GitHub: esta ficha refleja la última revisión del catálogo, no una consulta en directo. Verifica siempre en la documentación del módulo y en staging antes de instalar en producción.