Preguntas frecuentes

1: ¿Qué mecanismo de autenticación de API es compatible con Monotype Fonts?

Monotype Fonts es compatible con dos tipos de mecanismos de autenticación de API:

Tipo de concesión: credenciales de cliente

Uso práctico: este método resulta ideal cuando los usuarios necesitan iniciar sesión en nombre de una organización.

Funcionamiento: con este método, la organización utiliza su ID y su secreto de cliente únicos para autenticarse. Este método normalmente se emplea en la comunicación de máquina a máquina (M2M), en la que no hay interacción del usuario.

Seguridad: proporciona una forma segura para que los servidores se autentiquen y garantiza que solo las entidades de confianza puedan acceder a ciertos recursos.

Tipo de concesión: código de autorización con URL de redireccionamiento

Uso práctico: este método se usa cuando los usuarios finales de la API necesitan iniciar sesión.

Funcionamiento: en este supuesto, se redirige al usuario a la página URL de devolución de llamada (esta es la URL de redireccionamiento compartida por el usuario). Tras una autenticación correcta, Auth0 redirige al usuario a la aplicación con un código de autorización que luego se intercambia por un token de acceso.

Seguridad: este flujo añade una capa adicional de seguridad mediante el uso de una URL de redireccionamiento y garantiza que el token de acceso no quede expuesto en el navegador del usuario.

2: ¿Qué es el tipo de concesión? ¿Cómo puede usarse en relación con las API?

Los tipos (o flujos) de concesión de aplicaciones son métodos a través de los cuales las aplicaciones pueden obtener tokens de acceso. Esto te permite otorgar a otra entidad acceso limitado a tus recursos sin exponer tus credenciales. El protocolo OAuth 2.0 es compatible con varios tipos de concesiones para permitir distintos tipos de acceso.

Monotype Fonts admite los siguientes tipos de concesión:

authorization_code

El flujo de código de autorización (definido en la sección 4.1 del RFC 6749 de OAuth 2.0) implica el intercambio de un código de autorización por un token. Este flujo solo se puede utilizar para aplicaciones confidenciales (como aplicaciones web normales) porque los métodos de autenticación de la aplicación están incluidos en el intercambio y deben mantenerse seguros. El punto de conexión de API/oauth/autorización se usa para obtener el código de autorización. Acepta el ID de cliente y redirect_url (URL de redireccionamiento). Tras una ejecución correcta, el usuario recibe un código de autorización adjunto a su URL de redireccionamiento.

client_credentials

El flujo de credenciales de cliente (definido en la sección 4.4 del RFC 6749 de OAuth 2.0) implica que una aplicación intercambie sus credenciales de aplicación, como el ID y el secreto de cliente, por un token de acceso.

Este flujo resulta más adecuado para aplicaciones de máquina a máquina (M2M), como CLI, daemons o servicios de backend, ya que el sistema debe autenticar y autorizar la aplicación en lugar de un usuario.

refresh_token

Los tokens de actualización se emplean para solicitar un nuevo token de acceso o identificación para un usuario sin tener que volver a autenticarse.

Por lo general, debes solicitar un nuevo token de acceso antes de que caduque el anterior (para evitar cualquier interrupción del servicio), pero no cada vez que llamas a una API.

3: ¿Qué es la URI de redireccionamiento? ¿Cuándo y cómo se usa?

Una URI (identificador uniforme de recursos) de redireccionamiento es un componente esencial en los flujos de autenticación seguros, particularmente cuando se usa el tipo de concesión de código de autorización. Tiene dos propósitos principales:

Seguridad

La URI de redireccionamiento es donde tu aplicación recibe el código de autorización del servidor de autenticación. Está prerregistrada en el servidor de autenticación para evitar redireccionamientos maliciosos y garantiza que el código de autorización confidencial se envíe al lugar correcto.

Experiencia de usuario

Después de que un usuario inicia sesión o autoriza una aplicación, es necesario enviarlo de vuelta a la aplicación sin problemas. La URI de redireccionamiento facilita esta labor, ya que indica al servidor de autenticación la URL a la que el usuario ha de regresar una vez que se completa el proceso de autenticación.

Uso de la URI de redireccionamiento

Registro: el usuario comparte una URI de redireccionamiento en el momento del registro. Monotype Fonts registra esta URI en el servidor de autenticación mientras configura la aplicación del usuario.
Flujo de inicio de sesión: la aplicación incluye esta URI en la solicitud de autenticación enviada al servidor de autorización. Para obtener el código de autorización, selecciona la opción de autorizar el punto de conexión de API (/oauth/authorize) que acepta el ID de cliente (el ID y el secreto de cliente se comparten con los clientes como parte del proceso de incorporación) y redirige la URL en la carga útil. Por ejemplo:
```
curl --location 'https://api.monotype.com/v2/oauth/authorize?client_id=client_id&redirect_uri=redirect_uri'
```
Recepción del código de autorización: después de que el usuario se autentique, el servidor de autorización lo redirigirá a las URI registradas previamente e incluirá el código de autorización en los parámetros de consulta o en el parámetro de solicitud de la URI de redireccionamiento.

Preguntas basadas en supuestos

4: Tengo un token de acceso válido, pero no puedo ejecutar algunas API. ¿Por qué?

Cada aplicación del cliente en nuestro servidor de autorización está equipada con un conjunto único de permisos, conocidos como ámbitos. Estos ámbitos definen el nivel de acceso que tiene tu aplicación a las funciones de nuestra API. Los ámbitos comunes incluyen read:font:metadata, read:font:data y create:webfonts:kit.

Así pues, debes asegurarte de que el token de acceso de tu aplicación incluya todos los ámbitos necesarios (usa https://jwt.io/) para las funciones de API que deseas utilizar.

5: ¿Qué son el ID y el secreto de cliente? ¿Cómo se usan?

Un ID de cliente y un secreto de cliente son credenciales que se emplean para autenticar una aplicación con un servidor de autorización OAuth 2.0. Se asemejan a un nombre y a una contraseña de usuario, pero están destinados a que una aplicación registrada demuestre su identidad. El ID y el secreto de cliente se generan cuando una aplicación para el cliente está registrada en el servidor OAuth.

ID de cliente

El ID de cliente es un identificador único asignado a tu aplicación durante el proceso de registro. Sirve como una credencial que identifica de forma única tu aplicación cuando interactúa con el servidor de autenticación. El ID de cliente es un componente esencial en la autenticación que ayuda al servidor de autenticación a asociar las solicitudes de autenticación entrantes con tu aplicación específica. Se emplea para verificar la legitimidad de las solicitudes de autenticación y garantiza que solo las aplicaciones autorizadas obtengan acceso a los protocolos de autenticación y autorización del usuario. El ID de cliente suele combinarse con el secreto de cliente para mejorar la seguridad en el flujo de autenticación.

Secreto de cliente

El secreto de cliente es una credencial confidencial conocida únicamente por tu aplicación y el servidor de autenticación. Junto con el ID de cliente, añade una capa adicional de seguridad al proceso de autenticación. El secreto de cliente se utiliza durante el flujo de autenticación para autenticar tu aplicación al realizar solicitudes al servidor de autenticación para obtener tokens de acceso. Esto garantiza que solo las aplicaciones registradas y autorizadas, con el secreto de cliente correcto, puedan obtener tokens de acceso y autenticar usuarios. Es fundamental mantener la confidencialidad del secreto de cliente y nunca exponerlo en el código del lado del cliente o en repositorios públicos para salvaguardar la seguridad del proceso de autenticación.

6: ¿Qué son los tokens de acceso y actualización?

Los tokens de acceso y actualización son dos tipos de tokens que se utilizan para administrar las sesiones de usuario y el acceso a la API en aplicaciones seguras.

El token de acceso es un token web JSON (JWT) que emite el servidor de autorización para acceder a tu API. Es una credencial de tiempo limitado, normalmente válida durante 24 horas, que garantiza interacciones seguras y autenticadas entre tu aplicación y la API.

Un token de actualización es, igualmente, un token web JSON (JWT) que genera Auth0. Desempeña un papel vital en el mantenimiento del acceso continuo a tu API. Este token, válido durante un año, sirve como mecanismo seguro para obtener un nuevo token de acceso cuando caduca el actual. Es una credencial de un solo uso; una vez utilizado, se emite un nuevo token de actualización junto con el token de acceso actualizado. Es recomendable almacenar el último token de actualización de forma segura en el sistema para llevar a cabo una gestión de tokens fiable y fluida.

7: ¿Cómo puedo utilizar el token de actualización para generar un token de acceso?

El token de actualización se puede usar para volver a generar el token de acceso cuando el token de acceso actual ha caducado o está a punto de caducar. Para volver a generar el token, realiza una solicitud POST al punto de conexión /oauth/token en la API de autenticación usando grant_type=refresh_token. La funcionalidad del token de actualización solo resulta aplicable en el tipo de concesión de código de autorización.

Comando curl de ejemplo:

curl --request POST \  --url 'https://{apiGatewayHost}/v2/oauth/token' \  --header 'content-type: application/x-www-form-urlencoded' \  --header 'Authorization: Basic {base64Encode(clientId:clientSecret)}' \  --data grant_type=refresh_token&refresh_token={token}

8: ¿Qué es JWT?

Un JWT (JSON Web Token; un token web JSON) es un método conciso y autónomo para intercambiar información de manera segura entre partes en forma de objeto JSON. Los tokens JWT se usan con fines de autenticación, autorización e intercambio de información. Su fiabilidad se garantiza mediante firmas digitales, lo que salvaguarda la integridad y autenticidad de los datos transmitidos.

9: ¿Necesito un nuevo token de acceso para cada llamada API?

No. Lo ideal sería no crear un nuevo token JWT para cada llamada API. En su lugar, podemos crear un fragmento de código que identifique la caducidad del token y genere uno nuevo usando el token de actualización. A continuación puedes encontrar un comando curl de ejemplo que sirve para generar un nuevo token de acceso a partir de un token de actualización.

Nota: Generamos un token de actualización solo para el tipo de concesión authorization_code.

curl --request POST \  --url 'https://{apiGatewayHost}/v2/oauth/token' \  --header 'content-type: application/x-www-form-urlencoded' \  --header 'Authorization: Basic {base64Encode(clientId:clientSecret)}' \  --data grant_type=refresh_token&refresh_token={token}

10: ¿Cómo puedo garantizar un acceso óptimo a la API incluso cuando caduque el token de acceso?

Consulta la respuesta a la pregunta 9.

Cuando generamos un token de acceso, la carga útil de respuesta tiene un campo: expires_at. Al integrar API, podemos usar este campo para volver a generar condicionalmente un nuevo token antes de que caduque o esté a punto de caducar.

11: ¿Por qué aparece el error «The provided token does not have correct permissions to access this resource» («El token proporcionado no tiene los permisos correctos para acceder a este recurso»)?

Si encuentras limitaciones con tu token de acceso, es posible que el token no tenga los permisos necesarios (también conocidos como ámbitos) para acceder a determinadas funciones o datos. Para solucionarlo:

Verifica los permisos de tu token de acceso:

Los tokens de acceso contienen ámbitos que definen tus permisos. Puedes revisar los permisos de tu token para comprender qué acciones puedes llevar a cabo.

¿Cómo se comprueban los permisos?

Ve a jwt.io, una herramienta fiable para decodificar tokens web JSON (JWT).
Pega tu token de acceso en el decodificador. Verás la información del token decodificado, lo que incluye la matriz de permisos.

Permisos de versiones de muestra:

Por ejemplo, tu token podría incluir permisos como read:font:data, read:font:pair, read:font:preview y read:font:similar.

Siguientes pasos:

Si faltan los permisos necesarios, es posible que debas solicitar un token actualizado con los ámbitos correctos.
Si no sabes con certeza qué permisos se requieren o cómo solicitar permisos adicionales, ponte en contacto con nuestro equipo de atención al cliente para obtener ayuda.

12: ¿Cuál es el propósito del GUID contenido en las respuestas de error?

El GUID en el campo «Instance» (Instancia) sirve como un identificador único que señala la pila de errores exacta y los detalles en nuestro sistema. La inclusión de este GUID al notificar un error nos permite brindar una asistencia más efectiva y específica a la hora de resolver cualquier problema que puedas tener.

Nota: Comparte este identificador cuando desees obtener ayuda para facilitar una resolución más rápida y precisa.

Puedes encontrar una lista de códigos de error de alto nivel comunes en el siguiente enlace: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status.

13: ¿Qué es el límite de frecuencia? ¿Por qué experimento un error de límite de frecuencia para las llamadas API?

Un límite de frecuencia es un umbral que delimita la cantidad máxima de llamadas API que se pueden realizar en un periodo de tiempo determinado. Si excedes este límite, experimentarás un error de límite de frecuencia. Cuando se produce un error de límite de frecuencia, significa que la cantidad de solicitudes de API enviadas desde tu cuenta ha superado el límite permitido según nuestra política en el periodo de tiempo designado.

14: ¿Por qué aparece el error «Sorry, the functionality is not supported with client credentials. Please request for user specific token with authorization_code grant type» («Lo sentimos, la funcionalidad no es compatible con las credenciales de cliente. Solicita un token específico de usuario con el tipo de concesión authorization_code») en la importación de fuentes?

La funcionalidad de importación de fuentes solo está expuesta con tokens específicos de usuario (un token de acceso generado usando grant_type=authorization_code). Un token de acceso con grant_type:client_credentials no tiene el permiso (ámbito) requerido para la API de descarga de fuentes.

15: ¿Por qué aparece el error «Sorry, the functionality is not supported with client credentials. Please request for user specific token with authorization_code grant type» («Lo sentimos, la funcionalidad no es compatible con las credenciales de cliente. Solicita un token específico de usuario con el tipo de concesión authorization_code») en la biblioteca de fuentes?

La funcionalidad de la API de la biblioteca de fuentes solo está expuesta con tokens específicos de usuario (un token de acceso generado usando grant_type=authorization_code). Un token de acceso con grant_type:client_credentials no tiene el permiso (ámbito) requerido para la API.

16: ¿Puedo usar mi CDN para alojar fuentes y utilizar esta CDN en entornos de producción?

Debes abstenerte de usar tu CDN (red de entrega de contenido), especialmente si se trata de una CDN pública. Es recomendable utilizar la CDN de Monotype para extraer archivos de fuentes y utilizarlos en entornos de producción.

17: ¿Es posible implementar estrategias de almacenamiento en caché del lado del servidor para el alojamiento y la entrega eficientes de archivos de fuentes en respuesta a las solicitudes de los clientes?

Si bien el almacenamiento en caché del lado del servidor se puede emplear para diversas optimizaciones de entrega de contenido, no lo recomendamos para alojar y distribuir archivos de fuentes. En su lugar, recomendamos utilizar la CDN (red de entrega de contenido) de Monotype, que ofrece una mayor eficiencia y una capa adicional de seguridad para la entrega de archivos de fuentes. El uso de la CDN de Monotype garantiza que los archivos de fuentes se entreguen de conformidad con las prácticas recomendadas del sector. Ha de tenerse en cuenta que la aplicabilidad de esta recomendación puede variar en función de los términos específicos de tu acuerdo comercial. Para obtener información sobre una estrategia más personalizada y garantizar su ajuste a tus obligaciones contractuales, consulta a nuestro equipo comercial.