Obtenga un token de acceso OAuth 2.0
Use el flujo de portador JWT de OAuth 2.0 para obtener un token de acceso para las llamadas a la API entrante.
Las API entrantes D1 utilizan el flujo OAuth 2.0 JWT bearer (RFC 7523). Su sistema envía un JSON Web Token (JWT) firmado a /oauth2/token para obtener un token de acceso.
D1 también puede asegurar las API salientes con OAuth 2.0 bajo solicitud. Consulte la especificación OpenAPI de salida para el flujo compatible.
Use la especificación OpenAPI entrante para la /oauth2/token definición completa.
Cada recurso de la API backend a backend está protegido. Para obtener acceso a él, el Token de Acceso generado previamente debe enviarse junto con la solicitud HTTP en el encabezado Authorization usando el esquema Bearer:
Authorization: Bearer <access_token>
El token de acceso que se genera tiene una duración de 15 minutos, por lo que solo puede usarse durante 15 minutos; después de ese tiempo, el cliente tendrá que llamar nuevamente a la API /oauth2/token para obtener un token nuevo. Por razones de rendimiento, si su token aún está dentro de su período de validez, recomendamos que lo reutilice en lugar de llamar a la API /oauth2/token antes de cada llamada a la API.
JSON Web Token (JWT)
La API REST /oauth2/token requiere autenticación mediante JSON Web Token (JWT) (rfc7519). Se supone que los clientes de esta API son capaces de emitir tokens JWT válidos.
Los tokens JWT pueden obtenerse solicitándolos a un Proveedor de Identidad (como Keycloak) o crearse manualmente. En ambos casos, la clave pública que se usará para la verificación de la firma debe aprovisionarse en el sistema del proveedor de la API.
En el caso de que no haya un Proveedor de Identidad disponible, la siguiente sección describe cómo generar tokens JWT y las claves criptográficas que se usarán para emitir y verificar el JWT.
Algoritmos
Solo se admiten los JWT firmados con el algoritmo "ES256". Vea JSON Web Algorithms (JWA) (rfc7518).
La seguridad del JWT se limita a algoritmos de criptografía asimétrica para evitar almacenar secretos compartidos en el servidor de back-end. Como resultado, el servidor de back-end solo almacena las claves públicas utilizadas para verificar la firma de los tokens.
Formato JWT
Un JWT consta de tres partes separadas por puntos (.):
Encabezado
Carga útil
Firma
Por lo tanto, un JWT suele verse como lo siguiente: hhhhhhh.pppppppp.ssssssssss
Encabezado
La parte del encabezado contiene el algoritmo a usar y el tipo de token a generar.
El kid es obligatorio y se utilizará para determinar la clave correcta entre múltiples posibles claves públicas del mismo cliente.
Ejemplo de encabezado:
Carga útil
La carga útil puede contener los siguientes campos:
iss
El emisor del JWT. Debe ser el merchantGatewayId para las API entrantes y d1 para las API salientes y se utiliza para buscar la clave pública incorporada.
sub
El sujeto debe contener el identificador técnico del usuario. Aquí, para la API backend a backend, el sub es el merchantGatewayId.
exp
La hora de expiración del token expresada como el número de segundos desde el 1 de enero de 1970 (tiempo Epoch) en UTC. El valor máximo es la fecha/hora actual + 15 minutos.
aud
El campo aud identifica al servidor de autorización como una audiencia prevista. Por su parte, el servidor de autorización debe verificar que es una audiencia prevista para el token. Use la URL del servidor de autorización como valor de la audiencia: staging = stg , producción = prd
Notas sobre la expiración del JWT
El exp el valor se comprueba frente al periodo máximo de expiración. Si el exp valor del JWT excede el periodo máximo de expiración, el JWT se considera automáticamente inválido y la solicitud queda no autenticada.
Ejemplo de carga útil
Firma JWT
Un hash criptográfico tanto del encabezado como de la carga útil.
Estas partes se codifican en Base64URL y se concatenan, separadas por puntos simples ('.').
Cómo generar el par de claves
Puede usar la herramienta openssl para generar un par de claves con los siguientes comandos:
Ejemplo (ES256)
Genere la clave privada que se utilizará en el lado emisor y que DEBE protegerse de forma segura en su entorno.
Genere la clave pública que DEBE configurarse en D1.
La clave privada generada se utilizará para firmar los JWT en el lado del cliente y la clave pública generada se aprovisionará en el lado del servidor con el kid para verificar la firma de esos JWT (intercambiada entre el Cliente y Thales durante el Onboarding).
Cómo generar el JWT
Hay muchas herramientas disponibles para ayudar con la generación de JWT.
Aquí hay un ejemplo de cómo generarlo usando una pequeña librería de NodeJS:
Ejemplo de salida JWT
Última actualización
¿Te fue útil?