O que é Cliente?

O que é um cliente?

Um cliente, no contexto de OAuth 2.0 e OpenID Connect (OIDC) , é uma aplicação que solicita autenticação (authentication) ou autorização (authorization). Por exemplo, quando um usuário clica em “Entrar com Google” em uma aplicação, a aplicação está agindo como um cliente que solicita autorização ao Google.

“Cliente” e “aplicação” são frequentemente usados de forma intercambiável no contexto de Gerenciamento de identidade e acesso (IAM) .

Existem múltiplas categorizações de clientes com base em suas capacidades e níveis de confiança, mas para os frameworks, uma distinção significativa é entre clientes públicos e confidenciais. Isso afeta como o cliente pode obter tokens e os tipos de concessão que pode usar.

Clientes públicos

Clientes públicos são aplicações que não podem manter suas credenciais confidenciais, o que significa que o proprietário do recurso (usuário) pode acessá-las. Exemplos de clientes públicos incluem:

• Aplicações de página única (SPAs)
• Aplicativos móveis
• Aplicativos de desktop

Você pode argumentar que aplicativos móveis e de desktop têm capacidades de armazenamento seguro, mas a maioria dos frameworks os considera clientes públicos porque são distribuídos para usuários finais e presume-se que os usuários finais possam acessar as credenciais.

Clientes confidenciais

Clientes confidenciais (privados) são aplicações que podem armazenar informações sensíveis de forma confidencial sem expô-las aos proprietários dos recursos (usuários finais). Exemplos de clientes confidenciais incluem:

• Servidores web
• Serviços de backend

Como um cliente funciona?

Autenticação (authentication) e autorização (authorization) do usuário

Quando um cliente deseja autenticar um usuário, ele inicia uma Solicitação de autorização (Authorization request) para o Servidor de autorização para obter um Token de acesso (Access token) . O cliente deve incluir parâmetros necessários na solicitação, como o ID do cliente, URI de redirecionamento e escopos. Aqui está um diagrama de sequência simplificado do fluxo de código de autorização (authorization code flow):

Neste exemplo, o Google atua como o authorization server que emite um access token para o cliente (MyApp) após o usuário fazer login com sucesso. O cliente pode então usar o access token para buscar o perfil do usuário (recurso protegido) no Google.

Para clientes OpenID Connect (OIDC), o cliente precisa iniciar uma Solicitação de autenticação (Authentication request) para autenticar o usuário. Ele usa o mesmo endpoint da solicitação de autorização, mas os parâmetros e a resposta são diferentes.

Comunicação máquina a máquina

Para comunicação Comunicação máquina a máquina , o cliente pode usar o Fluxo de credenciais do cliente (Client credentials flow) para enviar diretamente uma Solicitação de token (Token request) para o authorization server. O cliente deve incluir o ID do cliente, segredo do cliente e escopos na solicitação. Aqui está um diagrama de sequência simplificado do fluxo de credenciais do cliente (client credentials flow):

O authorization server validará as credenciais do cliente e emitirá um access token se o cliente estiver autorizado. Como o cliente precisa enviar o segredo do cliente, é importante usar o fluxo de credenciais do cliente apenas para clientes confidenciais.

Considerações de segurança

Tipos de cliente

O tipo de cliente (público ou privado) afeta as considerações de segurança para o cliente.

• Clientes públicos não devem usar o fluxo de credenciais do cliente porque não podem armazenar o segredo do cliente de forma segura. Em vez disso, o Fluxo de código de autorização (Authorization code flow) com Chave de Prova para Troca de Código (PKCE) é recomendado para clientes públicos para autenticar usuários.
• Clientes confidenciais podem usar o fluxo de credenciais do cliente para comunicação máquina a máquina. Eles devem armazenar o segredo do cliente de forma segura e usá-lo apenas em ambientes seguros.

Armazenamento de tokens

Clientes devem usar o mais alto nível de segurança possível para armazenar tokens. Por exemplo, em aplicações web, cookies HTTP-only são recomendados para armazenar access tokens para prevenir ataques XSS.

Expiração de tokens

Access tokens têm um tempo de vida limitado para reduzir o risco de acesso não autorizado. Clientes devem lidar com a expiração de tokens de forma adequada usando refresh tokens para obter novos access tokens.

Revogação de tokens

Clientes devem estar preparados para lidar com a revogação de tokens. Se o usuário sair ou o authorization server revogar o token, o cliente deve limpar o token do armazenamento do lado do cliente.

Veja também

• OAuth 2.0
• Concessão OAuth 2.0 (OAuth 2.0 grant)
• OpenID Connect (OIDC)
• Solicitação de autorização (Authorization request)
• Solicitação de autenticação (Authentication request)