O que é Fluxo de credenciais do cliente (Client credentials flow)?

O que é o fluxo de credenciais do cliente (client credentials flow)?

O fluxo de credenciais do cliente (client credentials flow) (Grant) é um tipo de Concessão OAuth 2.0 (OAuth 2.0 grant) que permite que clientes confidenciais obtenham tokens de acesso (access tokens) para acessar recursos protegidos. Normalmente, este fluxo é usado para comunicação Comunicação máquina a máquina onde o cliente é um servidor ou um serviço.

[!Note] O fluxo de credenciais do cliente (client credentials flow) não é adequado para autorização de usuário final. Para autorização de usuário final, você deve usar Pedido de autenticação (Authentication request) ou Pedido de autorização (Authorization request) .

Como funciona o fluxo de credenciais do cliente (client credentials flow)?

O fluxo de credenciais do cliente (client credentials flow) é um processo simples de duas etapas:

1. Pedido de token (Token request): O cliente envia um Pedido de token (Token request) com suas credenciais de cliente (ID do cliente e segredo do cliente) e os escopos (scopes) solicitados.
2. Resposta de token (Token response): O Servidor de autorização valida as credenciais do cliente e emite um token de acesso (access token) se o cliente estiver autorizado.

Aqui está um diagrama de sequência simplificado do fluxo de credenciais do cliente (client credentials flow):

Aqui está um exemplo não normativo de um pedido de token no fluxo de credenciais do cliente (client credentials flow):

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

grant_type=client_credentials
  &client_id=YOUR_CLIENT_ID
  &client_secret=YOUR_CLIENT_SECRET
  &scope=read write

O servidor de autorização validará as credenciais do cliente e emitirá um token de acesso (access token) se o cliente estiver autorizado. Uma vez que o cliente recebe o token de acesso (access token), ele pode usá-lo para acessar recursos protegidos (por exemplo, uma API) em seu próprio nome. Aqui está um exemplo de como um cliente usa o token de acesso (access token) para acessar uma API:

Note que o Servidor de recursos deve validar o token de acesso (access token) e aplicar as políticas de Controlo de acesso para garantir que o cliente tenha as permissões necessárias para acessar o recurso.

Parâmetros chave em um pedido de token no fluxo de credenciais do cliente (client credentials flow)

Ao contrário de outros fluxos do OAuth 2.0, o fluxo de credenciais do cliente (client credentials flow) tem um Pedido de token (Token request) simples com os seguintes parâmetros chave:

• grant_type: O tipo de concessão deve ser definido como client_credentials para indicar o fluxo de credenciais do cliente (client credentials flow).
• client_id: O identificador do cliente emitido pelo servidor de autorização.
• client_secret: O segredo do cliente emitido pelo servidor de autorização.
• scope: Os escopos (scopes) solicitados (permissões) para o token de acesso (access token).
• resource: O parâmetro opcional que especifica o Indicador de recurso (Resource indicator) para os recursos solicitados. O servidor de autorização precisa suportar RFC 8707 para usar este parâmetro.

Considerações de segurança

Clientes confidenciais

O fluxo de credenciais do cliente (client credentials flow) é adequado para Clientes confidenciais (clientes confidenciais) que podem armazenar com segurança o segredo do cliente. Se o cliente for um cliente público (por exemplo, uma aplicação de página única), ele não deve usar o fluxo de credenciais do cliente (client credentials flow) porque o segredo do cliente pode ser exposto.

Expiração do token

Embora o token de acesso (access token) obtido no fluxo de credenciais do cliente (client credentials flow) possa ter um longo tempo de expiração, é recomendado usar tokens de acesso (access tokens) de curta duração (por exemplo, 1 hora) para reduzir o risco de acesso não autorizado se o token for comprometido.

Rotação do segredo do cliente

Para aumentar a segurança, é recomendado rotacionar o segredo do cliente periodicamente. O servidor de autorização deve suportar a rotação do segredo do cliente sem afetar a capacidade do cliente de obter tokens de acesso (access tokens). Por exemplo, o servidor de autorização deve suportar múltiplos segredos de cliente para compatibilidade retroativa durante o processo de rotação.

Veja também

• Comunicação máquina a máquina
• Pedido de token (Token request)
• Token de acesso (Access token)
• Scope (Scope)
• Indicador de recurso (Resource indicator)