Frequently Asked Questions

1: Which API authentication mechanism does Monotype Fonts support?

Monotype Fonts supports two types of authentication mechanisms for APIs:

Client Credentials Grant type

Use Case: This method is ideal when users need to log in on behalf of an organization.

How it Works: In this approach, the organization uses its unique client ID and secret to authenticate. This method is typically used for machine-to-machine (M2M) communication where no user interaction is involved.

Security: It provides a secure way for servers to authenticate and ensures that only trusted entities can access certain resources.

Authorization Code Grant type with Redirect URL

Use Case: This method is used when end users of API need to log in.

How it Works: In this scenario, the user is redirected to call back URL page (this is the redirect URL shared by the user). After successful authentication, Auth0 redirects the user back to the application with an authorization code, which is then exchanged for an access token.

Security: This flow adds an extra layer of security by using a redirect URL and ensures that the access token is not exposed in the user’s browser.

2: What is grant type? How to use grant types for APIs?

Application grant types (or flows) are methods through which applications can gain access tokens. This helps you to grant limited access to your resources to another entity without exposing credentials. The OAuth 2.0 protocol supports several types of grants to allow different types of access. Monotype Fonts supports the following grant types:

authorization_code

The Authorization Code Flow (defined in OAuth 2.0 RFC 6749, section 4.1), involves exchanging an authorization code for a token. This flow can only be used for confidential applications (such as Regular Web Applications) because the application's authentication methods are included in the exchange and must be kept secure. API endpoint /oauth/authorize is used to get the authorization code. It accepts client id and redirect_url. Upon successful execution, the user gets an authorization code appended to their redirect URL.

client_credentials

The Client Credentials Flow (defined in OAuth 2.0 RFC 6749, section 4.4) involves an application exchanging its application credentials, such as client ID and client secret, for an access token.

This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services, because the system must authenticate and authorize the application instead of a user.

refresh_token

Refresh tokens are used to request a new access token and/or ID token for a user without requiring them to re-authenticate.

Typically, you should request a new access token before the previous one expires (to avoid any service interruption), but not every time you call an API.

3: What is redirect URI? When and how to use redirect URI?

A Redirect URI, or Uniform Resource Identifier, is a critical component in secure authentication flows, particularly when using the Authorization Code Grant type. It serves two main purposes:

Security

The Redirect URI is where your application receives the authorization code from the authentication server. It is pre-registered with the authentication server to prevent malicious redirects and ensures that the sensitive authorization code is sent to the correct place.

User Experience

After a user logs in to or authorizes an application, the user needs to be sent back to the application seamlessly. The Redirect URI facilitates this by telling the authentication server the URL where the user should return once the authentication process is complete.

Using Redirect URI

Registration: User shares a Redirect URI at the time of registration. Monotype Fonts registers this URI on the authentication server while setting up the user application.
Login Flow: The application includes this URI in the authentication request sent to Authorization Server. To get the Authorization code, hit authorize API endpoint (/oauth/authorize) which accepts Client ID (ClientID and Client secret is shared with customers as part of onboarding process) and redirect URL in the payload. For example,
```
curl --location 'https://api.monotype.com/v2/oauth/authorize?client_id=client_id&redirect_uri=redirect_uri'
```
Receiving the authorization code: After the user authenticates, authorization server will redirect the user to the pre-registered URIs and will include the authorization code in the query parameters or request parameter of the Redirect URI.

Scenario based questions

4: I have a valid access token, but I am not able to execute some APIs. Why?

Each customer application on our Authorization Server is equipped with a unique set of permissions, known as scopes. These scopes define the level of access your application has to our API's functions. Common scopes include read:font:metadata, read:font:data, and create:webfonts:kit.

So please ensure that your application’s access token includes all the necessary scopes (use https://jwt.io/) for the API functions you want to use.

5: What is ClientID and client secret? How to use them?

A ClientID and client secret are credentials used to authenticate an application with an OAuth 2.0 authorization server. They are similar to a username and password for a user but are meant for a registered application to prove its identity. Client ID and Client secret are generated when an application for customer is registered OAuth server.

ClientID

The Client Id is a unique identifier assigned to your application during the registration process. It serves as a credential that uniquely identifies your application when interacting with the authentication server. The Client Id is a crucial component in the authentication that helps Auth server to associate incoming authentication requests with your specific application. It is used to verify the legitimacy of authentication requests, ensuring that only authorized applications gain access to user authentication and authorization processes. The Client ID is often paired with the Client Secret to enhance security in the authentication flow.

Client Secret

The Client Secret is a confidential credential, known only to your application and Auth Server. Paired with the Client Id, it adds an extra layer of security to the authentication process. The Client Secret is used during the authentication flow to authenticate your application when making requests to the Auth server for access tokens. This ensures that only registered and authorized applications, having the correct Client Secret, can obtain access tokens and authenticate users. It is essential to keep the Client Secret confidential and never expose it in client-side code or public repositories to maintain the security of your authentication process.

6: What is the access token and refresh token?

Access token and refresh token are two types of tokens used to manage user sessions and API access in secure applications.

The access token is a JSON Web Token (JWT) issued by Authorization Server to access your API. It is a time-limited credential, typically valid for 30 minutes, ensuring secure and authenticated interactions between your application and the API.

A refresh token is also a JSON Web Token (JWT) generated by Auth0. It plays a crucial role in maintaining continuous access to your API. Valid for one year, this token serves as a secure mechanism to obtain a new access token when the current one expires. It's a one-time-use credential—once utilized, a new refresh token is issued alongside the updated access token. It is advisable to store the latest refresh token securely in your system for seamless and secure token management.

7: How can I use refresh token to generate access token?

Refresh token can be used to regenerate the access token when the current access token has expired or is about to expire. To regenerate your token, make a POST request to the /oauth/token endpoint in the Authentication API, using grant_type=refresh_token. Refresh token functionality is only for grant type authorization code.

Sample 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: What is JWT?

A JWT, or JSON Web Token, is a concise and self-contained method for securely exchanging information between parties in the form of a JSON object. JWT tokens are used for authentication, authorization, and information exchange. Its trustworthiness is guaranteed by digital signatures, ensuring the integrity and authenticity of the transmitted data.

9: Do I need a new access token for each API call?

No. Ideally, we should not create a new JWT token for each API call. Instead, we can create some code snippet which identifies the token expiry and generates a new token using refresh token. Please find below a sample curl to generate a new access token out of a refresh token.

Note: We generate refresh token only for grant type 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: How do I ensure seamless access to the API even when the access token expires?

Refer to the response for question no 9.

When we generate an access token, the response payload has a field, expires_at. When integrating APIs, we can use this field to conditionally regenerate a new token before it expires or is about to expire.

11: Why do I get the error "The provided token does not have correct permissions to access this resource"?

If you encounter limitations with your access token, it's possible that the token does not have the necessary permissions (also known as scopes) to access certain features or data. To address this:

Check permissions of your access token:

Access tokens contain scopes that define your permissions. You can review your token's permissions to understand what actions you can perform.

How to check the permissions?

Go to jwt.io, a trusted tool for decoding JSON Web Tokens (JWT).
Paste your access token into the decoder. You'll see the decoded token information, including the permissions array.

Sample Permissions:

For example, your token might include permissions like read:font:data, read:font:pair, read:font:preview, and read:font:similar.

Next Steps:

If the necessary permissions are missing, you may need to request an updated token with the correct scopes.
If you are not sure about which permissions are required, or how to request additional permissions, please reach out to our support team for assistance.

12: What is the purpose of the GUID contained in error responses?

The GUID in the "Instance" field serves as a unique identifier pinpointing the exact error stack and details within our system. Including this GUID when reporting an error enables us to provide more effective and targeted assistance in resolving any issues you might encounter.

Note: Share this identifier when seeking support to facilitate a quicker and more accurate resolution.

A list of common high-level error codes can be found here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

13: What is the rate limit? Why do I get rate limit error for API calls?

A rate limit is a threshold that defines the maximum number of API calls that can be made within a certain time period. If you exceed this limit, you will receive a rate limit error. When you hit a rate limit error, it signifies that the number of API requests sent from your account has surpassed the permitted limit as per our policy within the designated timeframe.

14: Why do I get the error message, "Sorry, the functionality is not supported with client credentials. Please request for user specific token with authorization_code grant type" for fonts import?

Fonts import functionality is only exposed with user specific tokens (an access token generated using grant_type = Authorization_code) . An access token with grant_type : client_credentials does not have the required permission (scope) for font download API.

15. Why do I get the error message, "Sorry, the functionality is not supported with client credentials. Please request for user specific token with authorization_code grant type" for fonts my library.

Fonts Library API functionality is only exposed with user specific tokens (an access token generated using grant_type = Authorization_code) . An access token with grant_type : client_credentials does not have the required permission (scope) for the API.

16: Can I use my CDN to host fonts and use this CDN for production site?

You should refrain from using your CDN (Content Delivery Network), especially if it is a public CDN. It is advisable to use Monotype’s CDN to pull font files and use in production environment.

17: Is it possible to implement server-side caching strategies for the efficient hosting and delivery of font files in response to client requests?

While server-side caching can be utilized for various content delivery optimizations, we do not recommend it for hosting and distribution of font files. Instead, we endorse the use of Monotype's CDN (Content Delivery Network), which offers enhanced efficiency and an added layer of security for the delivery of font files. The use of Monotype CDN ensures that font files are served in compliance with best industry practices. It is important to note that the applicability of this recommendation may vary depending on the specific terms of your business agreement. For details on a more tailored approach and to ensure alignment with your contractual obligations, consult with our business team.