Logo Logo
GitHub Designed by Logto

O que é um pedido de token (token request)?

No OAuth 2.0 e OpenID Connect (OIDC) , um pedido de token (token request) é um pedido ao Servidor de autorização (ou OpenID Provider (OP) em OIDC) para troca de credenciais (por exemplo, código de autorização, refresh token) por um conjunto de tokens. O conjunto de tokens normalmente inclui um ou mais dos seguintes:

Dependendo do tipo de concessão (grant type) usado, o pedido pode incluir diferentes parâmetros e retornar diferentes tokens.

Por exemplo, no Fluxo de credenciais do cliente (Client credentials flow) , o Cliente solicita diretamente um Token de acesso (Access token) com credenciais do cliente. Aqui está um exemplo não normativo do pedido de token:

POST /token HTTP/1.1
Host: authorization-server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
  &client_id=client-id
  &client_secret=client-secret
  &scope=read

Se o pedido for bem-sucedido, o authorization server responde com um access token:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "eyJhbGci...zHg",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read"
}

Como funciona um pedido de token (token request)?

Como mostra o exemplo acima, o pedido de token em si é direto. O cliente envia um pedido HTTP ao endpoint de token do authorization server com os parâmetros necessários. O authorization server valida o pedido, processa-o e retorna os tokens na resposta.

No entanto, de acordo com o tipo de concessão (fluxo) específico usado, o pedido de token pode precisar de mais preparação.

Fluxo de código de autorização (Authorization code flow)

No Fluxo de código de autorização (Authorization code flow) , o cliente primeiro obtém um código de autorização iniciando um Pedido de autorização (Authorization request) (ou Pedido de autenticação (Authentication request) em OIDC) com o authorization server. Uma vez que o usuário concede permissão, o cliente troca o código de autorização por um access token e, opcionalmente, um refresh token através do pedido de token.

Aqui está um diagrama de sequência simplificado do fluxo de código de autorização:

Fluxo de credenciais do cliente (Client credentials flow)

Como o exemplo na primeira seção mostra, o Fluxo de credenciais do cliente (Client credentials flow) é muito mais simples. O cliente solicita diretamente um access token com suas credenciais de cliente. O authorization server valida as credenciais do cliente e emite um access token se for bem-sucedido.

Aqui está um diagrama de sequência não normativo do fluxo de credenciais do cliente:

Refresh token

Em alguns tipos de concessão, o cliente também pode solicitar Acesso offline (Offline access) incluindo o offline_access scope no pedido de autorização. Se concedido, o authorization server emite um refresh token juntamente com o access token. O cliente pode usar o refresh token para obter um novo access token através do pedido de token sem interação do usuário.

Aqui está um exemplo não normativo de uso de um refresh token para obter um novo access token:

POST /token HTTP/1.1
Host: authorization-server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
  &refresh_token=refresh-token
  &client_id=client-id
  &client_secret=client-secret

Outros tipos de concessão (grant types) também podem envolver pedidos de token, mas a ideia básica permanece a mesma.

Parâmetros chave em um pedido de token

Aqui estão alguns parâmetros chave que são comumente usados em um pedido de token:

  • grant_type: O tipo de concessão sendo solicitado. Valores comuns incluem authorization_code, client_credentials, refresh_token, etc.
  • client_id: O identificador do cliente emitido pelo authorization server.
  • client_secret: O segredo do cliente emitido pelo authorization server (para clientes confidenciais).
  • code: O código de autorização obtido do authorization server (para o fluxo de código de autorização).
  • refresh_token: O refresh token obtido do authorization server (para atualizar access tokens).
  • scope: Os scopes (permissões) solicitados para o access token.
  • redirect_uri: O URI onde o authorization server envia a resposta (para o fluxo de código de autorização).
  • code_verifier: O verificador de código usado na extensão Prova de Chave para Troca de Código (PKCE) (para o fluxo de código de autorização).

Os parâmetros reais e seus valores dependem do tipo de concessão e dos requisitos específicos da aplicação. Antes de fazer um pedido de token, você deve consultar a lista completa de parâmetros para o tipo de concessão específico que está usando.

Veja também