Os tokens são JWTs reais?

Não — access_token e refresh_token são UUIDs novos, não JWTs assinados. Se o seu cliente decodifica o token de acesso e lê as declarações (claims) dele, este modelo não irá satisfazê-lo; junte-o ao modelo JWKS e um token real assinado em vez disso.

Ele valida a concessão ou as credenciais do cliente?

Não. Ele nunca verifica client_id, client_secret ou o código de autorização, e sempre retorna a mesma resposta bem-sucedida. Para testar o caminho de falha, crie um segundo mock retornando um 400 com um corpo de erro OAuth2.

Como testo a expiração e atualização do token?

Diminua expires_in para alguns segundos para que a lógica de atualização do seu cliente seja acionada rapidamente. Como cada chamada retorna um novo refresh_token, você também pode confirmar que seu código armazena o mais recente em vez de reutilizar o original.

Simular uma resposta de token OAuth2

Um mock POST que retorna uma resposta de token em formato RFC 6749 com um access_token e refresh_token novos.

Este modelo retorna uma resposta de token em formato RFC 6749 — access_token, token_type, expires_in, refresh_token e scope — com valores de token novos em cada chamada. Ele permite que você crie a metade cliente de um fluxo OAuth2 antes que um provedor de identidade esteja disponível e teste se seu código armazena, atualiza e expira tokens corretamente.

Substitui um endpoint de API de terceiros.

Payload de resposta

{
  "access_token": "{{faker.uuid}}",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "{{faker.uuid}}",
  "scope": "read write"
}

Campos que valem a pena conhecer

Campo	O que significa
access_token	Um novo UUID em cada chamada via {{faker.uuid}} — não um token assinado real.
token_type	Codificado (hardcoded) como Bearer.
expires_in	Um tempo de vida codificado em segundos; edite para testar o tratamento de expiração.
refresh_token	Um novo UUID via {{faker.uuid}}.
scope	Escopos concedidos separados por espaço; edite para testar lógica com restrição de escopo.

Criar o mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "POST",
  "response_status": 200,
  "content_type": "application/json",
  "response_body": "{\"access_token\":\"{{faker.uuid}}\",\"token_type\":\"Bearer\",\"expires_in\":3600,\"refresh_token\":\"{{faker.uuid}}\",\"scope\":\"read write\"}"
}'

Chame-o

curl -X POST https://quickmock.dev/m/<slug>

O que você obtém

POST /m/<slug> -> 200 an RFC 6749-shaped token response
access_token/refresh_token are fresh UUIDs each call

Como isso difere do original

access_token e refresh_token são apenas UUIDs novos, não JWTs reais assinados, e o mock nunca verifica client_id, client_secret ou um código de autorização — ele sempre retorna a mesma resposta bem-sucedida.

Fontes

FAQ

Os tokens são JWTs reais?: Não — access_token e refresh_token são UUIDs novos, não JWTs assinados. Se o seu cliente decodifica o token de acesso e lê as declarações (claims) dele, este modelo não irá satisfazê-lo; junte-o ao modelo JWKS e um token real assinado em vez disso.
Ele valida a concessão ou as credenciais do cliente?: Não. Ele nunca verifica client_id, client_secret ou o código de autorização, e sempre retorna a mesma resposta bem-sucedida. Para testar o caminho de falha, crie um segundo mock retornando um 400 com um corpo de erro OAuth2.
Como testo a expiração e atualização do token?: Diminua expires_in para alguns segundos para que a lógica de atualização do seu cliente seja acionada rapidamente. Como cada chamada retorna um novo refresh_token, você também pode confirmar que seu código armazena o mais recente em vez de reutilizar o original.

Pronto para usar?

Abrir no construtor de mocks para ajustar primeiro

Combina bem com este guia: Simular um endpoint de API REST

Modelos relacionados

← Todos os modelos

Última atualização: 2026-10-17