Foire aux questions

1. Quel mécanisme d’authentification par API Monotype Fonts prend-il en charge ?

Monotype Fonts prend en charge deux types de mécanismes d’authentification pour les API :

Client Credentials Grant

Cas d’utilisation : cette méthode est idéale pour les utilisateurs qui doivent se connecter au nom d'une entreprise.

Mode de fonctionnement : cette approche consiste à s’authentifier à l’aide d’un ID client et d’un secret uniques. Elle est généralement utilisée pour les communications entre machines (M2M) qui n’impliquent aucune interaction avec l’utilisateur.

Sécurité : il s’agit d’un moyen sécurisé de s’authentifier aux serveurs, qui permet de s’assurer que seules les entités de confiance ont accès à certaines ressources.

Authorization Code Grant (Autorisation via un code) avec URL de redirection

Cas d’utilisation : cette méthode est utilisée par les utilisateurs finaux d’API ayant besoin de s’identifier.

Mode de fonctionnement : dans ce cas de figure, l’utilisateur est redirigé vers une page URL call back (qui est l’URL de redirection partagée par l’utilisateur). Une fois l’authentification réussie, Auth0 renvoie l’utilisateur à l’application au moyen d’un code d’autorisation, qu’il faut saisir afin d’obtenir un jeton d’accès.

Sécurité : ce flux ajoute un niveau de sécurité supplémentaire grâce au recours à une URL de redirection, et veille à ce que le jeton d’accès ne soit pas exposé dans le navigateur de l’utilisateur.

2. Qu’est-ce qu’un type d’attribution ? Comment utiliser un type d’attribution pour les API ?

Les types (ou flux) d’attribution pour une application correspondent aux méthodes utilisées par les applications pour obtenir un jeton d’accès. Ils vous permettent d’accorder un accès limité à vos ressources à une autre entité sans risque d’exposition des identifiants. Le protocole OAuth 2.0 prend en charge plusieurs types d’attribution pour autoriser différents types d’accès. Monotype Fonts prend en charge les types d’attribution suivants :

authorization_code

le Authorization Code Flow (défini dans la section 4.1 du document OAuth 2.0 RFC 6749) consiste à saisir un code d’autorisation en échange d’un jeton. Ce flux ne peut être utilisé que pour les applications confidentielles (telles que les applications Web standard), car les méthodes d’authentification de l’application font partie de l’échange et doivent être sécurisées. Le point de terminaison API /oauth/authorize est utilisé pour obtenir le code d’autorisation. Il accepte les méthodes par ID client et URL de redirection. Lorsque le processus a bien été exécuté, l’utilisateur reçoit un code d’autorisation via son URL de redirection.

client_credentials

le Client Credentials Flow (défini dans la section 4.4 du document Oauth 2.0 RFC 6749) consiste à échanger les identifiants d’une application, tels que l’ID client et le code secret client, contre un jeton d’accès.

Cette méthode est la mieux adaptée pour les applications Machine-to-Machine (M2M), comme par exemple les CLI, les daemons ou les services dorsaux, car le système doit authentifier et autoriser l’application plutôt que l’utilisateur.

refresh_token

les Refresh tokens ou jetons d’actualisation servent à demander un nouveau jeton d’accès et/ou jeton ID pour un utilisateur sans que celui-ci ait besoin de s’authentifier de nouveau.

En général, il est recommandé de demander un nouveau jeton d’accès avant l’expiration du jeton précédent (afin d’éviter toute interruption de service), mais pas chaque fois que vous faites appel à une API.

3. Qu’est-ce qu’un URI de redirection ? Quand et comment utiliser un URI de redirection ?

Un URI de redirection, ou Uniform Resource Identifier (identifiant de ressource uniforme), est un composant essentiel des flux d’authentification sécurisés, notamment pour le type d’attribution Authorization Code Grant. Il a deux fonctions principales :

La sécurité

l’URI de redirection correspond à l’emplacement avec lequel votre application reçoit le code d’autorisation du serveur d’authentification. Il est pré-enregistré sur le serveur d’authentification afin d’éviter les redirections malintentionnées, et veille à ce que le code d’autorisation sensible soit envoyé à la bonne destination.

L’expérience utilisateur

lorsque l’utilisateur s’identifie ou autorise l’accès d’une application, il doit être renvoyé vers l’application automatiquement. L’URI de redirection facilite l’opération en indiquant au serveur d’authentification l’adresse URL vers laquelle l’utilisateur doit être redirigé une fois le processus d’authentification terminé.

Comment l’utiliser

À l’enregistrement : au moment de l’enregistrement, l’utilisateur communique un URI de redirection. Monotype Fonts enregistre cet URI sur le serveur d’authentification lors de la configuration de l’application de l’utilisateur.

Pendant le flux de connexion : l’application inclut cet URI dans la demande d’authentification envoyée au serveur d’autorisation. Pour obtenir le code d’autorisation, cliquez sur le point de terminaison authorize API (/oauth/authorize), qui accepte l’ID client (L’ID client et le code secret client sont communiqués aux clients dans le cadre du processus d’intégration) et l’URL de redirection dans la charge utile.

Par exemple,

curl --location 'https://api.monotype.com/v2/oauth/authorize?client_id=client_id&redirect_uri=redirect_uri'

Lors de la réception du code d’autorisation : une fois l’authentification terminée, le serveur d’autorisation redirige l’utilisateur vers les URI pré-enregistrés et intègre le code d’autorisation dans les paramètres de requête ou de demande de l’URI de redirection.

Questions concernant différents cas de figure.

4. Je dispose d’un jeton d’accès valide, mais je n’arrive pas à exécuter certaines API. Pourquoi ?

Chaque application client sur notre serveur d’autorisation est configurée avec un ensemble unique de droits d’accès, appelés champs d’application. Ces champs d’application définissent le niveau d’accès aux fonctionnalités de notre API qui a été accordé à votre application. Les champs d’application habituels comprennent read:font:metadata, read:font:data et create:webfonts:kit. Vous devez donc vous assurer que le jeton d’accès de votre application comprend tous les champs d’application nécessaires (utilisez pour cela https://jwt.io/) pour les fonctionnalités de l’API dont vous avez besoin.

5. Qu’est-ce qu’un ID client et un code secret client ? Comment les utiliser ?

L’ID client et le code secret client sont les identifiants utilisés pour authentifier une application auprès d’un serveur d’autorisation OAuth 2.0. Tout comme un nom d’utilisateur et un mot de passe, ils permettent à une application enregistrée de prouver son identité. L’ID client et le code secret client sont générés lorsque l’application d’un client est enregistrée sur le serveur OAuth.

ID client

l’ID client est un identifiant unique attribué à votre application lors du processus d’enregistrement. Il identifie de manière unique votre application lorsqu’elle interagit avec le serveur d’authentification. L’ID client est un élément crucial qui aide le serveur Auth à associer les demandes d’authentification entrantes à votre application spécifique. Il permet de vérifier le bien-fondé des demandes d’authentification, veillant à ce que seules les applications autorisées aient accès aux processus d’authentification et d’autorisation de l’utilisateur. L’ID client est souvent rattaché à un code secret client afin de renforcer la sécurité du flux d’authentification.

Code secret client

le Client Secret est un identifiant confidentiel que seuls votre application et le serveur Auth connaissent. Couplé à l’ID client, il apporte un niveau de sécurité supplémentaire au processus d’authentification. Le code secret client est utilisé durant le flux d’authentification lorsque vous envoyez une demande au serveur Auth en vue d’obtenir des jetons d’accès. Il veille à ce que seules les applications enregistrées et autorisées qui disposent du bon code secret client puissent obtenir des jetons d’accès et authentifier des utilisateurs. Le code secret client doit rester confidentiel et ne jamais être exposé dans le code client-side (côté client) ou dans les dépôts (référentiels) publics, afin de préserver la sécurité de votre processus d’authentification.

6. Qu’est-ce qu’un jeton d’accès et un jeton d’actualisation ?

L’Access token (jeton d’accès) et le refresh token (jeton d’actualisation) sont deux types de jetons utilisés pour gérer les sessions des utilisateurs ainsi que l’accès à l’API dans les applications sécurisées.

Le jeton d’accès est un JSON Web Token (JWT) émis par le serveur d’autorisation afin d’accéder à votre API. Il s’agit d’un identifiant à durée limitée, qui expire généralement au bout de 24 heures et qui assure des interactions sécurisées et authentifiées entre votre application et l’API.

Le jeton d’actualisation est également un JSON Web Token (JWT) généré par Auth0. Il joue un rôle crucial dans la continuité d’accès à votre API. Valable pendant un an, le jeton d’actualisation est un mécanisme sécurisé qui permet d’obtenir un nouveau jeton d’accès lorsque le jeton existant expire. Il ne peut être utilisé qu’une fois. Lorsqu’il est utilisé, un nouveau jeton d’actualisation est émis, ainsi que le jeton d’accès mis à jour. Nous vous recommandons de conserver votre dernier jeton d’actualisation dans votre système pour faciliter et sécuriser la gestion de vos jetons.

7. Comment utiliser un jeton d’actualisation pour générer un jeton d’accès ?

Le jeton d’actualisation peut être utilisé pour générer un nouveau jeton d’accès lorsque votre jeton d’accès existant a expiré ou est sur le point d’expirer. Pour générer un nouveau jeton, envoyez une demande POST au point de terminaison /oauth/token dans l’API d’authentification en indiquant grant_type=refresh_token. Le jeton d’actualisation fonctionne uniquement pour le type d’attribution par code d’autorisation.

Voici un exemple de curl :

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’est-ce qu’un JWT ?

Un JWT, ou JSON Web Token, est une méthode concise et autonome pour sécuriser les échanges d’informations entre des parties sous la forme d’un élément JSON. Les jetons JWT sont utilisés pour l’authentification, l’autorisation et l’échange d’informations. Des signatures digitales assurent sa fiabilité ainsi que l’intégrité et l’authenticité des données transmises.

9. Ai-je besoin d’un nouveau jeton d’accès pour chaque demande d’API ?

Non. Dans l’idéal, il ne faut pas créer un nouveau jeton JWT pour chaque demande d’API. À la place, nous pouvons créer un extrait de code qui identifie la date d’expiration de votre jeton et en génère un nouveau à l’aide du jeton d’actualisation. Vous trouverez ci-dessous un exemple de curl qui vous permettra de générer un nouveau jeton d’accès à partir d’un jeton d’actualisation.

Remarque : les jetons d’actualisation ne sont générés que pour les types d’attribution 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. Comment assurer mon accès à l’API même lorsque le jeton d’accès arrive à expiration ?

Veuillez vous reporter à la réponse à la question 9. Lorsque nous générons un jeton d’accès, la charge utile de réponse comprend le champ expires_at. Lors de l’intégration d’API, nous pouvons utiliser ce champ pour générer un nouveau jeton sous certaines conditions si le vôtre a expiré ou est sur le point d’expirer.

11. Pourquoi l’erreur « The provided token does not have correct permissions to access this resource » se produit-elle ?

Si vous faites face à des restrictions lors de l’utilisation de votre jeton d’accès, cela signifie peut-être que le jeton ne dispose pas des droits d’accès nécessaires (également appelés champs d’application) pour accéder à certaines fonctionnalités ou données. Pour résoudre ce problème :

Vérifiez les droits de votre jeton d’accès :

Les jetons d’accès comprennent des champs d’application qui définissent vos autorisations. Vérifiez les droits d’accès de votre jeton pour savoir quelles actions vous pouvez effectuer.

Comment vérifier les autorisations ?

Ouvrez jwt.io, un outil fiable qui permet de décoder les jetons JSON Web Tokens (JWT).
Collez votre jeton d’accès dans le décodeur. Les informations du jeton décodé ainsi que ses droits d’accès s’afficheront.

Exemple de droits d’accès :

Votre jeton peut inclure des droits d’accès comme read:font:data, read:font:pair, read:font:preview et read:font:similar.

Étapes suivantes :

Si le jeton n’est pas associé aux droits nécessaires, vous devrez peut-être demander un nouveau jeton comportant les bons scopes (champs d’application).
Si vous ne savez pas de quels droits d’accès vous avez besoin, ou comment demander des droits supplémentaires, n’hésitez pas à contacter notre équipe d’assistance pour obtenir de l’aide.

12. Quelle est la fonction du GUID contenu dans les réponses-erreurs ?

Le GUID dans le champ « Instance » est un identifiant unique qui localise précisément la pile d’erreurs et les détails de l’erreur dans notre système. Il est important d’indiquer ce GUID lorsque vous signalez une erreur, afin que nous puissions vous aider plus efficacement à résoudre les problèmes que vous rencontrez.

Remarque : communiquez cet identifiant lorsque vous faites appel à nous afin de résoudre plus facilement, rapidement et précisément le problème.

Le lien suivant vous présente une liste des codes d’erreur à haut risque les plus courants : https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

13. Qu’est-ce que la rate limit (limite de débit) ? Pourquoi une erreur de limite de débit survient-elle lors des demandes d’API ?

Une limite de débit correspond au seuil qui définit le nombre maximum de demandes d’API pouvant être effectuées dans un délai donné. Si vous dépassez cette limite, vous recevrez une erreur de limite de débit. Lorsque cela se produit, cela signifie que le nombre de demandes d’API envoyées depuis votre compte a dépassé la limite autorisée par notre politique dans le délai indiqué.

14. Pourquoi le message d’erreur « Sorry, the functionality is not supported with client credentials. Please request for user specific token with authorization_code grant type » s’affiche-t-il lors de l’importation de fontes ?

La fonctionnalité d’importation de fontes est uniquement accessible à l’aide de jetons spécifiques à l’utilisateur (un jeton d’accès généré à l’aide d’un type d’attribution grant_type = Authorization_code). Les jetons d’accès générés à l’aide de grant_type : client_credentials ne disposent pas des droits d’accès requis (scope) pour accéder au téléchargement de fontes.

15. Pourquoi le message d’erreur « Sorry, the functionality is not supported with client credentials. Please request for user specific token with authorization_code grant type » s’affiche-t-il lorsque je tente d’accéder à ma bibliothèque de fontes ?

La fonctionnalité de bibliothèque de fontes est uniquement accessible à l’aide de jetons spécifiques à l’utilisateur (un jeton d’accès généré à l’aide d’un grant_type = Authorization_code). Les jetons d’accès générés à l’aide de grant_type : client_credentials ne disposent pas des droits d’accès requis (scope) pour accéder à l’API.

16. Puis-je utiliser mon CDN pour héberger des polices et pour la production ?

Vous devez éviter d’utiliser votre CDN (Content Delivery Network), en particulier s’il s’agit d’un CDN public. Nous vous recommandons d’utiliser le CDN de Monotype pour extraire des fichiers de fontes et pour la production.

17. Puis-je mettre en place des stratégies de server-side caching (mise en cache côté serveur) afin d’améliorer l’efficacité de l’hébergement et de la livraison des fichiers de fontes pour répondre aux demandes des clients ?

Bien que la mise en cache côté serveur puisse être utilisée pour diverses optimisations de la livraison de contenus, nous la déconseillons pour l’hébergement et la distribution des fichiers de fontes. Nous recommandons plutôt le CDN (Content Delivery Network) de Monotype, qui offre une plus grande efficacité et un niveau de sécurité supplémentaire pour la livraison de fichiers de polices. Le CDN de Monotype assure la conformité des fichiers de fontes avec les meilleures pratiques du secteur. Veuillez noter que cette suggestion n’est pas forcément applicable selon les conditions spécifiques de votre accord. Pour une approche plus personnalisée et pour garantir que nos services répondent à vos obligations contractuelles, veuillez contacter notre équipe dédiée aux entreprises.