Autenticación
Las API de REST de Marketo utilizan OAuth 2.0 de 2 patas para la autenticación. Un servicio personalizado proporciona el ID de cliente y el Secreto de cliente utilizados para obtener un token de acceso.
Cada servicio personalizado pertenece a un usuario solo de API. Las funciones y los permisos del usuario autorizan al servicio a realizar acciones específicas. Un token de acceso pertenece a un único servicio personalizado y su caducidad es independiente de los tokens de otros servicios personalizados de la instancia.
Creación de un token de acceso
Para encontrar Client ID y Client Secret, vaya a Administración > Integración > LaunchPoint. Seleccione el servicio personalizado y, a continuación, seleccione Ver detalles.
Para encontrar Identity URL, vaya a Administración > Integración > Servicios web. La dirección URL aparece en la sección API de REST.
Cree un token de acceso con una petición HTTP GET o POST:
GET <Identity URL>/oauth/token?grant_type=client_credentials&client_id=<Client Id>&client_secret=<Client Secret>
Si su solicitud era válida, recibe una respuesta JSON similar a la siguiente:
{
"access_token": "cdf01657-110d-4155-99a7-f986b2ff13a0:int",
"token_type": "bearer",
"expires_in": 3599,
"scope": "apis@acmeinc.com"
}
La respuesta contiene los campos siguientes:
access_token: el token que pasa con las llamadas subsiguientes para autenticarse con la instancia de destino.token_type: método de autenticación de OAuth.expires_in: la duración restante del token actual, en segundos. Un nuevo token de acceso tiene una duración de 3600 segundos o una hora.scope: el usuario propietario del servicio personalizado usado para autenticarse.
Uso de un token de acceso
Cada llamada a la API de REST debe incluir un token de acceso en un encabezado HTTP.
access_token se eliminó el 31 de agosto de 2026. El nuevo desarrollo debe utilizar exclusivamente el encabezado Authorization.Este cambio es una corrección de seguridad para ajustarse a las Prácticas recomendadas de seguridad del sector y de OAuth 2.0, que recomiendan no transmitir tokens de acceso en las direcciones URL. Es posible que los flujos de trabajo existentes que se autentican de esta manera ya estén experimentando errores 603 (Acceso denegado).
Priorice la actualización de la integración para utilizar la autenticación basada en encabezado antes del 15 de septiembre de 2026. Si necesita más tiempo, póngase en contacto con el Soporte técnico de Adobe para discutir las opciones disponibles
Cambio al encabezado Autorización
Para reemplazar el parámetro de consulta access_token por un encabezado de Autorización, actualice la forma en que la solicitud envía el token.
El siguiente ejemplo de cURL envía el valor access_token como parámetro de formulario con el indicador -F:
curl ... -F access_token=<Access Token> <REST API Endpoint Base URL>/bulk/v1/apiCall.json
El ejemplo siguiente envía el mismo valor en el encabezado HTTP Authorization: Bearer con el indicador -H:
curl ... -H 'Authorization: Bearer <Access Token>' <REST API Endpoint Base URL>/bulk/v1/apiCall.json
Sugerencias y prácticas recomendadas
Almacene el token de acceso y el periodo de caducidad de la respuesta de identidad. La administración de la caducidad del token ayuda a evitar errores de autenticación inesperados durante el funcionamiento normal.
Antes de realizar una llamada de REST, compruebe la vida útil restante del token. Si el token ha caducado, renuévelo llamando al extremo Identity. La renovación proactiva evita errores causados por tokens caducados y hace que la latencia de las llamadas a REST sea más predecible, lo que es importante para las aplicaciones del usuario final.
Los errores de autenticación devuelven los códigos siguientes:
602: el token de acceso ha caducado.601: token de acceso no válido.
Si el cliente recibe cualquiera de los códigos, renueve el token llamando al punto de conexión de identidad.
Si llama al extremo de identidad antes de que caduque el token, la respuesta devolverá el mismo token y la duración restante.
Los tokens de acceso pertenecen a servicios personalizados, no a usuarios. Si las credenciales de dos servicios diferentes producen respuestas de identidad con ámbito para el mismo usuario, sus tokens de acceso y períodos de caducidad siguen siendo independientes.
Cuando una aplicación utiliza varios conjuntos de credenciales, utilice el ID de cliente como clave para administrar cada token de forma independiente.