Skip to main content
El token OAuth ES256 demuestra la identidad, pero nunca es aceptado por las APIs de negocio de B Brands. Cuando un cliente necesita leer/escribir datos de B Brands en nombre del usuario, intercambia su token OIDC por un JWT interno de B Brands (el mismo formato HS256 que el login tradicional) y lo usa como Bearer. El autorizador interno existente lo valida con el propio RBAC del usuario.
Dos endpoints de “exchange” diferentes — no los confundas:
  • POST /api/v3/oauth/exchange → un cliente OAuth externo convierte un token OIDC en un JWT interno de B Brands (esta página).
  • POST /api/v3/auth/sso/exchange → handshake de sesión entre apps internas de B Brands. Consulta Inicio de sesión social.

​
POST /api/v3/oauth/exchange

Implementa un intercambio de tokens simplificado al estilo RFC 8693.
​
string
requerido
El token OIDC emitido por el IdP para el usuario (id_token o access_token).
​
string
Aceptado por paridad con RFC 8693; no se exige.
​
string
Aceptado por paridad con RFC 8693; no se exige.

​
Qué hace el endpoint

1

Verifica el subject token

Firma ES256 contra JWKS, más iss, aud, exp. Rechaza tokens expirados o inválidos con 401.
2

Verifica la blacklist

Si el jti del token está en la blacklist, rechaza con 401.
3

Resuelve usuario y cliente

user_id desde sub, el cliente desde el claim https://bbrands.io/client_handle. Un claim faltante devuelve 401.
4

Valida la habilitación

El acceso usuario × plataforma debe estar activo y el cliente debe estar activo. De lo contrario 403.
5

Resuelve la cuenta primaria y acuña el JWT

Acuña el JWT interno HS256 con user_id, account_id, token_use: "exchange", el handle del cliente y un jti, con un TTL corto (por defecto 900s, configurable). Registra la emisión con grant_type = token_exchange.

​
Errores

​
Uso del token intercambiado

El cliente usa el token devuelto como Authorization: Bearer ... contra las APIs de B Brands. El autorizador interno existente valida el JWT HS256 y resuelve los permisos propios del usuario (RBAC interno). El Resource Server no cambia.

​
Notas de seguridad

El JWT intercambiado transporta los permisos completos del usuario en B Brands (sin least-privilege por cliente). Esto es aceptable para clientes first-party confiables. Si se requiere acotación, introdúcela en el exchange (limita el conjunto de permisos por cliente).
  • El TTL corto es obligatorio (por defecto 900s). Nunca emitas el token de login tradicional de larga duración a través de este flujo.
  • El token es revocable vía la blacklist por jti. Tanto este endpoint como el autorizador interno rechazan los tokens en blacklist.
  • No hay refresh para el token interno por diseño. Cuando expira, el cliente vuelve a ejecutar el exchange con un token OIDC aún válido.

​
Máquina a máquina (sin usuario)

Para procesos sin un usuario interactivo (p. ej. un cron de sincronización), no uses OAuth ni este exchange. Usa el modelo de API key existente de B Brands, aprovisionado con least privilege. Consulta Integración de clientes.