API (Habilitar configurações do OAuth): Controle de configurações de fluxo de credenciais e código de autorização

Nome do controle

Aplicativos conectados: API (Habilitar configurações do OAuth): Configurações de código e fluxo de credenciais de autorização

Configuração recomendada

Habilite o Fluxo de credenciais e código de autorização.

Não exija nem desmarque Exigir segredo para fluxo de servidor da Web e Exigir segredo para fluxo de token de atualização.

Visão geral de controle

Esse controle configura os requisitos de segurança específicos para o "Fluxo de credenciais e código de autorização", determinando se um segredo do cliente deve ser validado com base em se o aplicativo é um "Cliente privado" (no lado do servidor) ou um "Cliente público" (browser/móvel).

Risco de segurança, se não configurado

Exigir incorretamente um segredo para clientes públicos força a codificação permanente de credenciais para o código de front-end em que eles são facilmente roubados, enquanto não exigir um segredo para clientes privados permite que os invasores troquem códigos interceptados sem precisar da chave privada do aplicativo.

Cenários de ameaça

Um invasor descompila um aplicativo móvel para extrair um segredo do cliente embutido em código ou intercepta um código de autorização de um aplicativo no lado do servidor e o troca com sucesso por um token de acesso de alto privilégio porque nenhum segredo era necessário para a troca.

Intervalo de pontuação de CVSS estimado

Crítico (9.0 a 10.0).

Considerações sobre impacto de risco

Uma configuração incorreta leva ao comprometimento das credenciais do cliente ou à ativação de sequestro de sessão não autorizado, ambos resultando em acesso persistente e não autenticado a dados confidenciais.

Risco maior quando

Quando o fluxo é usado para integrações de alto privilégio que não têm PKCE (Proof Key for Code Exchange) como uma defesa secundária ou quando os segredos são armazenados em repositórios de texto simples no lado do cliente.

Baixo risco quando

Quando "clientes privados" impõem estritamente segredos armazenados em cofres seguros no lado do servidor e "clientes públicos" usam a PKCE para proteger a troca sem precisar de um segredo compartilhado vulnerável.

Considerações de negócios e integração

Implementar isso corretamente requer uma distinção arquitetônica clara entre aplicativos orientados por back-end e orientados por front-end para garantir que a política "Secreto" apropriada seja aplicada sem quebrar o apelido de autenticação.

Remediação recomendada

Para clientes privados/do lado do servidor, selecione "Exigir segredo para fluxo de servidor da Web" e "Exigir segredo para fluxo de token de atualização"; Para clientes públicos/móveis, desmarque essas opções e implemente a PKCE.

Diretriz de revisão de saúde de segurança

A Análise de integridade de segurança destaca que a segurança de um segredo depende inteiramente da capacidade do cliente de protegê-lo e determina que nenhum segredo compartilhado seja exposto ao navegador ou ao ambiente móvel.