Aplicações de clientes públicos e confidenciais
A Microsoft Authentication Library (MSAL) define dois tipos de clientes; clientes públicos e clientes confidenciais. Um cliente é uma entidade de software que tem um identificador exclusivo atribuído por um provedor de identidade. Os tipos de cliente distinguem-se pela sua capacidade de autenticação segura com o servidor de autorização e de manter informações confidenciais de prova de identidade para que não possam ser acedidas ou conhecidas por um utilizador no âmbito do seu acesso.
| Aplicativos cliente públicos | Aplicativos cliente confidenciais |
|---|---|
 Aplicação de ambiente de trabalho |
 Aplicação Web |
 API sem navegador |
 Web API |
 Aplicação móvel |
Serviço/daemon |
Autorização de cliente público e confidencial
Ao examinar a natureza pública ou confidencial de um determinado cliente, estamos avaliando a capacidade desse cliente de provar sua identidade ao servidor de autorização. Isso é importante porque o servidor de autorização deve ser capaz de confiar na identidade do cliente para emitir tokens de acesso.
Os aplicativos cliente públicos são executados em dispositivos, como desktop, APIs sem navegador, aplicativos de navegador móveis ou do lado do cliente. Eles não podem ser confiáveis para manter segredos de aplicativos com segurança, portanto, só podem acessar APIs da Web em nome do usuário. Sempre que o código-fonte ou bytecode compilado de um determinado aplicativo é transmitido para qualquer lugar onde possa ser lido, desmontado ou inspecionado por partes não confiáveis, é um cliente público. Como eles também suportam apenas fluxos de clientes públicos e não podem manter segredos de tempo de configuração, eles não podem ter segredos de cliente.
Os aplicativos cliente confidenciais são executados em servidores, como aplicativos Web, aplicativos de API da Web ou aplicativos de serviço/daemon. Eles são considerados de difícil acesso por usuários ou invasores e, portanto, podem armazenar adequadamente segredos de tempo de configuração para afirmar a prova de sua identidade. O ID do cliente é exposto através do navegador da web, mas o segredo é passado apenas no canal traseiro e nunca diretamente exposto.
Quando você deve habilitar a permissão de um fluxo de cliente público no registro do seu aplicativo?
Depois de determinar o tipo de aplicativo cliente que você está criando, você pode decidir se deseja habilitar o fluxo de cliente público no registro do seu aplicativo. Por padrão, permitir fluxo de cliente público em seu registro de aplicativo deve ser desabilitado, a menos que você ou seu desenvolvedor estejam criando um aplicativo cliente público e usando o seguinte protocolo ou recursos de autorização OAuth:
| Protocolo/recurso de autorização OAuth | Tipo de aplicativo cliente público | Exemplos/notas |
|---|---|---|
| Autenticação nativa | Aplicativo de ID Externo Microsoft Entra que requer personalização completa da interface do usuário, incluindo elementos de design, posicionamento do logotipo e layout, garantindo uma aparência consistente e com a marca. | Observação: a Autenticação Nativa só está disponível para registros de aplicativos em locatários de ID Externa do Microsoft Entra. Saiba mais aqui |
| Fluxo de código do dispositivo | Aplicativos executados em dispositivos com restrição de entrada, como uma smart TV, dispositivo IoT ou impressora | |
| Fluxo de credenciais de senha do proprietário do recurso | Aplicativos que lidam com senhas que os usuários entram diretamente, em vez de redirecionar os usuários para o site de login hospedado do Entra e permitir que o Entra manipule a senha do usuário de maneira segura. | A Microsoft recomenda que você não use o fluxo ROPC. Na maioria dos cenários, alternativas mais seguras, como o fluxo de código de autorização, estão disponíveis e são recomendadas. |
| Fluxo de autenticação integrado do Windows | Aplicativos móveis ou de desktop executados no Windows ou em uma máquina conectada a um domínio do Windows (Microsoft Entra ID ou Microsoft Entra ingressado) usando o Windows Integrated Auth Flow em vez do gerenciador de contas da Web | Um aplicativo de desktop ou móvel que deve ser conectado automaticamente depois que o usuário entrou no sistema Windows PC com uma credencial Microsoft Entra |
Segredos e sua importância na comprovação da identidade
A seguir estão alguns exemplos de como um cliente pode provar sua identidade para o servidor de autorização:
- Identidades gerenciadas para recursos do Azure – Para cenários de autenticação somente de aplicativo, os desenvolvedores de aplicativos e serviços baseados no Azure têm a opção de descarregar gerenciamento, rotação e proteção secretos para a própria plataforma. Com identidades gerenciadas, as identidades são fornecidas e excluídas com recursos do Azure e ninguém, incluindo o Administrador Global, pode acessar as credenciais subjacentes. Usando identidades gerenciadas, você pode evitar o risco de vazamento de segredos e deixar o provedor lidar com a segurança para você.
- ID do cliente e segredo – Neste padrão, um par de valores é gerado pelo servidor de autorização ao registrar um cliente. O ID do cliente é um valor público que identifica o aplicativo, enquanto o segredo do cliente é um valor confidencial usado para provar a identidade do aplicativo.
- Comprovar a posse de um certificado – Infraestrutura de Chave Pública (PKI), que inclui padrões como X.509, é a tecnologia fundamental que permite uma comunicação segura pela internet e forma a espinha dorsal da privacidade na internet. A PKI é usada para emitir certificados digitais que verificam a identidade das partes envolvidas na comunicação on-line e é a tecnologia subjacente que alimenta protocolos como HTTPS, que é amplamente usado para proteger o tráfego da web. Da mesma forma, os certificados podem ser usados para proteger a comunicação serviço-a-serviço (S2S) no Azure habilitando a autenticação mútua entre os serviços. Trata-se de cada serviço apresentar um certificado ao outro como meio de prova da sua identidade.
- Apresentação de uma asserção assinada – Usadas na federação de identidades de carga de trabalho, as asserções assinadas permitem a troca de um token de provedor de identidade de terceiros confiável com a plataforma de identidade da Microsoft para obter tokens de acesso para chamar recursos protegidos do Microsoft Entra. A federação de identidades de carga de trabalho pode ser usada para habilitar vários cenários de federação, incluindo o Serviço Kubernetes do Azure, o EKS da Amazon Web Services, as Ações do GitHub e muito mais.
Quando é que a comprovação da identidade do cliente é importante?
A comprovação da identidade do cliente é importante quando há a necessidade de verificar a autenticidade e a autorização de um aplicativo cliente antes de conceder acesso a dados ou recursos confidenciais. Alguns exemplos incluem:
- Controlando o acesso à API – Se você tiver uma API que é medida (como para faturamento) ou expõe dados ou recursos confidenciais, você verificará a identidade do cliente antes de conceder acesso. Por exemplo, isso é importante ao garantir que apenas aplicativos autorizados tenham acesso à API e que o cliente correto seja cobrado pelo uso limitado da API.
- Protegendo os usuários contra a representação do aplicativo – Se você tiver um aplicativo implantado por serviço e voltado para o usuário (como um aplicativo Web orientado por back-end) que acessa dados ou serviços confidenciais, usar segredos de cliente para proteger os recursos usados por esse aplicativo pode impedir que agentes mal-intencionados se passem por um cliente legítimo para enganar usuários e exfiltrar dados ou abusar do acesso.
- Comunicação S2S – Se você tiver vários serviços de back-end (como APIs downstream) que precisam se comunicar entre si, poderá verificar a identidade de cada serviço para garantir que eles estejam autorizados a acessar apenas os recursos necessários para executar sua função.
Em geral, provar a identidade do cliente é importante quando há a necessidade de autenticar e autorizar um cliente independente ou além de um usuário.
Clientes confidenciais: melhores práticas para a gestão de segredos
Use identidades gerenciadas para simplificar a implantação e a segurança – As identidades gerenciadas fornecem uma identidade gerenciada automaticamente na ID do Microsoft Entra para os aplicativos usarem ao se conectar a recursos que oferecem suporte à autenticação do Microsoft Entra. Os aplicativos podem usar identidades gerenciadas para obter tokens somente de aplicativo do Microsoft Entra ID sem precisar gerenciar credenciais. Isso pode remover muitas das complexidades associadas ao gerenciamento de segredos, aumentando sua segurança e resiliência. Se você estiver usando identidades gerenciadas, a maioria, se não todas, as práticas recomendadas a seguir já foram atendidas para você.
Use armazenamento seguro – armazene os segredos do cliente em um local seguro, como o Cofre da Chave ou um arquivo de configuração criptografado. Evite armazenar segredos do cliente em texto sem formatação ou como arquivos com check-in em sistemas de controle de versão.
Limitar o acesso - Limitar o acesso aos segredos do cliente apenas a pessoal autorizado. Use o controle de acesso baseado em função para restringir o acesso aos segredos do cliente apenas àqueles que precisam dele para executar suas funções operacionais.
Girar segredos do cliente – A rotação dos segredos do cliente conforme necessário ou programado pode minimizar o risco de um segredo comprometido ser usado para obter acesso não autorizado. Quando aplicado, o período de tempo durante o qual se sugere que uma chave permaneça em uso é influenciado pela força do algoritmo criptográfico usado e/ou pela adesão a normas ou práticas de conformidade regulamentar.
Use segredos longos e criptografia forte – Intimamente relacionado ao ponto anterior, o uso de algoritmos de criptografia fortes para dados em trânsito (no fio) e em repouso (no disco) ajuda a garantir que segredos de alta entropia permaneçam improváveis de serem forçados a bruto. Algoritmos como o AES-128 (ou superior) podem ajudar a proteger os dados em repouso, enquanto o RSA-2048 (ou superior) pode ajudar a proteger eficientemente os dados em trânsito. Devido à natureza em constante evolução da cibersegurança, é sempre uma boa prática consultar os seus especialistas em segurança e rever periodicamente a sua seleção de algoritmos.
Evite segredos de hardcoding – Não codifice segredos de cliente no código-fonte. Evitar segredos no código-fonte pode minimizar o valor de agentes mal-intencionados que obtêm acesso ao seu código-fonte. Também pode evitar que esses segredos sejam acidentalmente empurrados para repositórios inseguros ou disponibilizados a contribuidores do projeto que poderiam ter acesso à fonte, mas não acesso secreto.
Monitore repositórios em busca de segredos vazados – É um fato lamentável que check-ins ruins aconteçam ao lidar com código-fonte. Os ganchos de pré-confirmação do Git são uma maneira sugerida de evitar check-ins acidentais, mas também não substituem o monitoramento. O monitoramento automatizado de repositórios pode identificar segredos vazados e, com um plano em vigor para alternar credenciais comprometidas, pode ajudar a reduzir incidentes de segurança.
Monitore atividades suspeitas – Monitore logs e trilhas de auditoria em busca de atividades suspeitas relacionadas a segredos de clientes. Sempre que possível, use alertas automatizados e processos de resposta para notificar o pessoal e definir contingências para atividades incomuns relacionadas a segredos de clientes.
Arquitete seus aplicativos com o sigilo do cliente em mente – Seu modelo de segurança é tão forte quanto o elo mais fraco da cadeia. Não encaminhe credenciais de segurança ou tokens de clientes confidenciais para clientes públicos, pois isso pode mover dados secretos do cliente para um cliente público, permitindo a representação do cliente confidencial.
Use bibliotecas e SDKs atualizados de fontes confiáveis – A plataforma de identidade da Microsoft fornece vários SDKs e middleware de cliente e servidor projetados para aumentar sua produtividade enquanto mantém seus aplicativos seguros. Bibliotecas como Microsoft.Identity.Web simplificam a adição de autenticação e autorização a aplicativos Web e APIs na plataforma de identidade da Microsoft. Manter as dependências atualizadas ajuda a garantir que seus aplicativos e serviços se beneficiem das mais recentes inovações e atualizações de segurança.
Comparando os tipos de clientes e suas capacidades
A seguir estão algumas semelhanças e diferenças entre aplicativos cliente públicos e confidenciais:
- Ambos os tipos de aplicativo mantêm um cache de token de usuário e podem adquirir um token silenciosamente (quando o token está presente no cache). Os aplicativos cliente confidenciais também têm um cache de token de aplicativo para tokens adquiridos pelo próprio aplicativo.
- Ambos os tipos de aplicativo podem gerenciar contas de usuário e obter uma conta do cache de token de usuário, obter uma conta de seu identificador ou remover uma conta.
- No MSAL, os aplicativos cliente públicos têm quatro maneiras de adquirir um token, por meio de fluxos de autenticação separados. Os aplicativos cliente confidenciais têm apenas três maneiras de adquirir um token e uma maneira de calcular a URL do ponto de extremidade de autorização do provedor de identidade. O ID do cliente é passado uma vez na construção do aplicativo e não precisa ser passado novamente quando o aplicativo adquire um token. Para obter mais informações, consulte Aquisição de tokens.
Os clientes públicos são úteis para permitir o acesso delegado pelo usuário a recursos protegidos, mas não conseguem provar sua própria identidade de aplicativo. Os clientes confidenciais, por outro lado, podem realizar autenticação e autorização de usuários e aplicativos e devem ser construídos com a segurança em mente para garantir que seus segredos não sejam compartilhados com clientes públicos ou outros terceiros.
Em alguns casos, como a comunicação S2S, a infraestrutura, como identidades gerenciadas, ajuda muito a simplificar o desenvolvimento e a implantação de serviços e remove grande parte da complexidade normalmente associada ao gerenciamento secreto. Quando as identidades gerenciadas não podem ser usadas, é importante ter políticas, medidas preventivas e contingências em vigor para proteger segredos e responder a incidentes de segurança relacionados a eles.
Consulte também
Para obter mais informações sobre configuração e instanciação de aplicativos, consulte: