ota:invoke y ota:register
La plataforma distingue el alta inicial del tenant en el Hub (onboarding administrativo)
del uso en operación de canales OTA (p. ej. GetYourGuide) y del registro del backend en Iterpax Connect.
El runtime usa OAuth 2.0 con client_credentials y private_key_jwt
hacia el Hub; los tokens que circulan hacia Connect y hacia los backends Tierra son JWT RS256
emitidos por el Hub y validables con JWKS público.
POST /client/register, usando cifrado simétrico
con la API key del Hub (ITERPAX_HUB_API_KEY / iterpax.hub.apikey).
Este camino no sustituye al OAuth de runtime hacia Connect.
ITERPAX_HUB_ID en parámetros de sistema).
POST /oauth2/token con
grant_type=client_credentials, client_assertion (JWT firmado con clave privada M2M)
y datos de contexto (iterpax_routing_id, supplier_id, channel).
access_token (JWT) según el scope solicitado.
POST /internal/register con
Authorization: Bearer (token con scope ota:register), sin usar el token cifrado del bootstrap.
El cliente machine-to-machine (Tierra y/o Connect) comparte un client_id y un par de claves RSA:
la clave privada solo en el cliente que firma la aserción; la clave pública en el Hub
(HUB_OAUTH2_CLIENTS_JSON) para verificar el client_assertion.
La audiencia esperada en esa aserción se configura con HUB_OAUTH2_CLIENT_ASSERTION_AUD
(debe coincidir con la URL del endpoint de token del Hub).
ota:invoke y ota:registerEn un mismo pedido de token solo puede pedirse uno de estos scopes (no se combinan):
ota:invoke: JWT para que el tráfico OTA (p. ej. llamadas proxy a productos en el backend Tierra)
lleve un Bearer emitido por el Hub, con audiencia típica de backend OTA (HUB_OTA_AUDIENCE).
ota:register: JWT para POST /internal/register en Connect,
con audiencia específica de registro (HUB_CONNECT_REGISTRATION_AUDIENCE), alineada entre Hub y Connect.
El Hub expone las claves públicas para verificar esos JWT en GET /.well-known/jwks.json.
| Componente | Función en este esquema |
|---|---|
| Tierra (backend) |
Firma private_key_jwt hacia el Hub; solicita tokens ota:register para registrar el canal en Connect
y ota:invoke para validar conectividad o tráfico OTA según la API.
|
| Iterpax Hub |
Endpoint /oauth2/token; emisión de JWT OTA; JWKS; registro bootstrap /client/register (flujo aparte).
|
| Iterpax Connect |
POST /internal/register protegido por validación JWT (ota:register);
rutas de canal (p. ej. GYG) con Bearer validado frente al Hub.
|
Los nombres exactos pueden variar según el despliegue; suelen incluir:
HUB_OAUTH2_CLIENT_ASSERTION_AUD, HUB_OAUTH2_CLIENTS_JSON,
HUB_OTA_ISSUER, HUB_OTA_AUDIENCE, HUB_CONNECT_REGISTRATION_AUDIENCE,
HUB_OTA_JWT_PRIVATE_KEY_B64 (o equivalente PEM), HUB_OTA_JWT_KID.HUB_ITERPAX_URL, HUB_OTA_ISSUER,
HUB_CONNECT_REGISTRATION_AUDIENCE, credenciales M2M alineadas con el Hub.iterpax.hub.oauth.* (client id, audiencia de aserción, clave privada M2M),
iterpax.hub.url, iterpax.connect.url, etc.
La audiencia de registro en Connect debe ser idéntica en Hub y Connect para que la validación del JWT de
ota:register sea correcta.