Perguntas frequentes

1: Quais mecanismos de autenticação de API a Monotype Fonts são compatíveis?

A Monotype Fonts é compatível com dois tipos de mecanismos de autenticação para APIs:

Tipo de concessão de credenciais do cliente

Caso de uso: Esse método é ideal quando os usuários precisam fazer login em nome de uma organização.

Como funciona: Nesse enfoque, a organização utiliza seu Client ID e Cliente Secret exclusivos para autenticar. Este método é tipicamente usado para comunicação máquina a máquina (M2M), onde não há interação do usuário envolvida.

Segurança: Ele fornece uma maneira segura para que os servidores se autentiquem e garante que apenas entidades confiáveis possam acessar determinados recursos.

Tipo de concessão de código de autorização com URL de redirecionamento

Caso de uso: Esse método é utilizado quando os usuários finais da API precisam fazer login.

Como funciona: Nesse cenário, o usuário é redirecionado para a página do URL de callback (este é o URL de redirecionamento compartilhado pelo usuário). Após a autenticação bem-sucedida, o Auth0 redireciona o usuário de volta para a aplicação com um código de autorização, que é então trocado por um token de acesso.

Segurança: Esse fluxo adiciona uma camada extra de segurança ao utilizar um URL de redirecionamento e garante que o token de acesso não seja exposto no navegador do usuário.

2: O que é um tipo de concessão? Como usar os tipos de concessão para APIs?

Os tipos de concessão (ou fluxos) de aplicação são métodos pelos quais as aplicações podem obter tokens de acesso. Isso permite conceder acesso limitado aos seus recursos a outra entidade sem expor credenciais. O protocolo OAuth 2.0 suporta vários tipos de concessão para permitir diferentes tipos de acesso. A Monotype Fonts é compatível com os seguintes tipos de concessão:

authorization_code

O fluxo de código de autorização (definido na RFC 6749 do OAuth 2.0, seção 4.1) envolve a troca de um código de autorização por um token. Esse fluxo pode ser utilizado apenas por aplicações confidenciais (como aplicações Web regulares) porque os métodos de autenticação da aplicação estão incluídos na troca e devem ser mantidos em segurança. O endpoint da API /oauth/authorize é utilizado para obter o código de autorização. Ele aceita Client ID e redirect_url. Após a execução bem-sucedida, o usuário recebe um código de autorização anexado ao seu URL de redirecionamento.

client_credentials

O fluxo de credenciais do cliente (definido na RFC 6749 do OAuth 2.0, seção 4.4) envolve uma aplicação trocando suas credenciais, como Client ID e Client Secret, por um token de acesso.

Esse fluxo é mais adequado para aplicações máquina a máquina (M2M), como CLIs, daemons ou serviços de backend, pois o sistema deve autenticar e autorizar a aplicação em vez de um usuário.

refresh_token

Os tokens de atualização são usados para solicitar um novo token de acesso e/ou token de ID para um usuário sem exigir que ele se reautentique.

Normalmente, você deve solicitar um novo token de acesso antes que o anterior expire (para evitar qualquer interrupção no serviço), mas não a cada vez que você chama uma API.

3: O que é um URI de redirecionamento? Quando e como usar o URI de redirecionamento?

Um URI de redirecionamento, ou identificador uniforme de recurso, é um componente crucial em fluxos de autenticação segura, especialmente ao utilizar o tipo de concessão de código de autorização. Ele desempenha duas funções principais:

Segurança

O URI de redirecionamento é o local onde sua aplicação recebe o código de autorização do servidor de autenticação. Ela é pré-registrada junto ao servidor de autenticação para prevenir redirecionamentos maliciosos e garantir que o código de autorização sensível seja enviado ao lugar correto.

Experiência do usuário

Após um usuário fazer login ou autorizar uma aplicação, é necessário que ele seja enviado de volta à aplicação de forma fluida. O URI de redirecionamento facilita isso, informando ao servidor de autenticação o URL para o qual o usuário deve retornar assim que o processo de autenticação estiver completo.

Utilizando o URI de redirecionamento

Registro: O usuário compartilha um URI de redirecionamento no momento do registro. A Monotype Fonts registra esse URI no servidor de autenticação ao configurar a aplicação do usuário.
Fluxo de login: A aplicação inclui esse URI na solicitação de autenticação enviada ao servidor de autorização. Para obter o código de autorização, acesse o endpoint da API de autorização (/oauth/authorize), que aceita o Client ID (o Client ID e o Client Secret são compartilhados com os clientes como parte do processo de integração) e o URL de redirecionamento no payload. Por exemplo,
```
curl --location 'https://api.monotype.com/v2/oauth/authorize?client_id=client_id&redirect_uri=redirect_uri'
```
Recebendo o código de autorização: Após a autenticação do usuário, o servidor de autorização redirecionará o usuário aos URIs pré-registrados e incluirá o código de autorização nos parâmetros de consulta ou nos parâmetros de solicitação do URI de redirecionamento.

Perguntas baseadas em cenários

4: Tenho um token de acesso válido, mas não consigo executar algumas APIs. Por quê?

Cada aplicação de cliente em nosso servidor de autorização é equipada com um conjunto exclusivo de permissões, conhecido como escopos. Esses escopos definem o nível de acesso que sua aplicação possui às funções da nossa API. Os escopos comuns incluem read:font:metadata, read:font:data e create:webfonts:kit.

Portanto, certifique-se de que o token de acesso da aplicação inclua todos os escopos necessários (use https://jwt.io/) para as funções da API que você deseja utilizar.

5: O que são ClientID e Client Secret? Como usá-los?

Um ClientID e um Client Secret são credenciais usadas para autenticar uma aplicação com um servidor de autorização OAuth 2.0. Eles são semelhantes a um nome de usuário e senha para um usuário, mas são destinados a uma aplicação registrada para comprovar sua identidade. O Client ID e o Client Secret são gerados quando uma aplicação do cliente é registrada no servidor OAuth.

ClientID

O Client ID é um identificador único atribuído à sua aplicação durante o processo de registro. Ele funciona como uma credencial que identifica de forma exclusiva sua aplicação ao interagir com o servidor de autenticação. O Client ID é um componente crucial na autenticação, pois ajuda o servidor de autenticação a associar as solicitações de autenticação recebidas à sua aplicação específica. É utilizado para verificar a legitimidade das solicitações de autenticação, garantindo que apenas aplicações autorizadas tenham acesso aos processos de autenticação e autorização de usuários. O Client ID geralmente é associado ao Client Secret para aumentar a segurança no fluxo de autenticação.

Client Secret

O Client Secret é uma credencial confidencial, conhecida apenas pela sua aplicação e pelo servidor de autenticação. Junto com o Client ID, ele adiciona uma camada extra de segurança ao processo de autenticação. O Client Secret é utilizado durante o fluxo de autenticação para validar sua aplicação ao fazer solicitações ao servidor de autenticação em busca de tokens de acesso. Isso assegura que apenas aplicações registradas e autorizadas, que possuam o Client Secret correto, consigam obter tokens de acesso e autenticar usuários. É fundamental manter o Client Secret em sigilo e nunca o expor em códigos do lado do cliente ou em repositórios públicos para garantir a segurança do seu processo de autenticação.

6: O que são o token de acesso e o token de atualização?

O token de acesso e o token de atualização são dois tipos de tokens utilizados para gerenciar sessões de usuários e o acesso à API em aplicações seguras.

O token de acesso é um JSON Web Token (JWT) emitido pelo servidor de autenticação para acessar sua API. É uma credencial com tempo limitado, normalmente válida por 24 horas, garantindo interações seguras e autenticadas entre sua aplicação e a API.

O token de atualização também é um JSON Web Token (JWT) gerado pelo Auth0. Ele desempenha um papel crucial na manutenção do acesso contínuo à sua API. Com validade de um ano, esse token serve como um mecanismo seguro para obter um novo token de acesso quando o atual expira. É uma credencial de uso único – uma vez utilizada, um novo token de atualização é emitido juntamente com o token de acesso atualizado.

Recomenda-se armazenar o último token de atualização com segurança em seu sistema para uma gestão contínua e segura dos tokens.

7: Como posso usar o token de atualização para gerar um token de acesso?

O token de atualização pode ser utilizado para regenerar o token de acesso quando o token atual expira ou está prestes a expirar. Para regenerar seu token, faça uma solicitação POST ao endpoint /oauth/token na API de autenticação, utilizando grant_type=refresh_token. A funcionalidade do token de atualização é válida apenas para o tipo de concessão authorization_code.

Exemplo 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: O que é JWT?

Um JWT, ou JSON Web Token, é um método conciso e autônomo para a troca segura de informações entre partes na forma de um objeto JSON. Os tokens JWT são utilizados para autenticação, autorização e troca de informações. Sua confiabilidade é garantida por assinaturas digitais, assegurando a integridade e autenticidade dos dados transmitidos.

9: Preciso de um novo token de acesso para cada chamada de API?

Não. O ideal é não criar um novo token JWT para cada chamada de API. Em vez disso, podemos criar um trecho de código que identifique a expiração do token e gere um novo token utilizando o token de atualização. Abaixo está um exemplo de curl para gerar um novo token de acesso a partir de um token de atualização.

Observação: Geramos o token de atualização apenas para o tipo de concessão 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: Como posso garantir um acesso contínuo à API mesmo quando o token de acesso expira?

Consulte a resposta para a pergunta número 9.

Quando geramos um token de acesso, o payload de resposta contém um campo chamado expires_at. Ao integrar APIs, podemos usar esse campo para regenerar condicionalmente um novo token antes que ele expire ou esteja prestes a expirar.

11: Por que recebo o erro “O token fornecido não tem as permissões corretas para acessar este recurso”?

Se você encontrar limitações com seu token de acesso, é possível que o token não tenha as permissões necessárias (também conhecidas como escopos) para acessar certas funcionalidades ou dados. Para resolver isso:

Verifique as permissões do token de acesso:

Os tokens de acesso contêm escopos que definem suas permissões. Você pode revisar as permissões do token para entender quais ações pode realizar.

Como verificar as permissões?

Acesse jwt.io, uma ferramenta confiável para decodificar JSON Web Tokens (JWT).
Cole seu token de acesso no decodificador. Você verá as informações decodificadas do token, incluindo a matriz de permissões.

Exemplo de permissões:

Por exemplo, seu token pode incluir permissões como read:font:data, read:font:pair, read:font:preview e read:font:similar.

Próximos passos:

Se as permissões necessárias estiverem ausentes, você pode precisar solicitar um token atualizado com os escopos corretos.
Se você não tiver certeza sobre quais permissões são necessárias ou como solicitar permissões adicionais, entre em contato com nossa equipe de suporte para assistência.

12: Qual é o propósito do GUID contido nas respostas de erro?

O GUID no campo “Instance” serve como um identificador exclusivo que aponta para a pilha de erros exata e detalhes dentro do sistema. Incluir esse GUID ao relatar um erro nos permite fornecer uma assistência mais eficaz e direcionada na resolução de quaisquer problemas que você possa encontrar.

Observação: Compartilhe esse identificador ao buscar suporte para facilitar uma resolução mais rápida e precisa.

Uma lista de códigos de erro comuns de alto nível pode ser encontrada aqui: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

13: O que é limite de taxa? Por que recebo erro de limite de taxa para chamadas de API?

Um limite de taxa é um limite que define o número máximo de chamadas de API que podem ser feitas dentro de um determinado período de tempo. Se você ultrapassar esse limite, receberá um erro de limite de taxa. Quando você encontra um erro de limite de taxa, isso significa que o número de solicitações de API enviadas da sua conta ultrapassou o limite permitido de acordo com nossa política dentro do período designado.

14: Por que recebo a mensagem de erro “Desculpe, a funcionalidade não é compatível com credenciais de cliente. Solicite um token específico do usuário com o tipo de concessão authorization_code” para importação de fontes?

A funcionalidade de importação de fontes só está disponível com tokens específicos do usuário (um token de acesso gerado usando grant_type = Authorization_code). Um token de acesso com grant_type: client_credentials não possui a permissão necessária (escopo) para a API de download de fontes.

15. Por que recebo a mensagem de erro “Desculpe, a funcionalidade não é compatível com credenciais de cliente. Solicite um token específico do usuário com o tipo de concessão authorization_code” para a biblioteca de fontes?

A funcionalidade da API da biblioteca de fontes só está disponível com tokens específicos do usuário (um token de acesso gerado usando o tipo de concessão authorization_code). Um token de acesso com o tipo de concessão client_credentials não possui as permissões necessárias (escopo) para a API.

16: Posso usar meu CDN para hospedar fontes e usar este CDN em um site de produção?

Recomenda-se não usar sua rede de distribuição de conteúdo (CDN), especialmente se for uma CDN pública. É aconselhável utilizar a CDN Monotype para puxar arquivos de fonte e usá-los no ambiente de produção.

17: É possível implementar estratégias de cache no lado do servidor para um armazenamento eficiente e entrega de arquivos de fontes em resposta às solicitações do cliente?

Embora o cache no lado do servidor possa ser utilizado para várias otimizações de entrega de conteúdo, não recomendamos seu uso para hospedagem e distribuição de arquivos de fontes. Em vez disso, endossamos a utilização da CDN Monotype, que oferece maior eficiência e uma camada adicional de segurança para a entrega de arquivos de fontes. O uso da CDN Monotype garante que os arquivos de fontes sejam entregues em conformidade com as melhores práticas do setor. É importante notar que a aplicabilidade dessa recomendação pode variar dependendo dos termos específicos do seu contrato. Para detalhes sobre uma abordagem mais personalizada e para garantir o alinhamento com suas obrigações contratuais, consulte nossa equipe comercial.