Aplicativos cliente públicos e confidenciais
A Biblioteca de Autenticação da Microsoft (MSAL) define dois tipos de clientes: públicos e confidenciais. Um cliente é uma entidade de software que tem um identificador exclusivo atribuído por um provedor de identidade. Os tipos de cliente são diferenciados por sua capacidade de autenticar com segurança com o servidor de autorização e manter informações confidenciais e de prova de identidade para que elas não possam ser acessadas ou conhecidas por um usuário dentro do escopo de seu acesso.
| Aplicativos cliente públicos | Aplicativos cliente confidenciais |
|---|---|
 Aplicativo da área de trabalho |
 Aplicativo Web |
 API sem uso de navegador |
 API Web |
 Aplicativo móvel |
Serviço/daemon |
Autorizações de clientes públicos e confidenciais
Ao examinar a natureza pública ou confidencial de um determinado cliente, estamos avaliando a capacidade desse cliente de provar sua identidade para o 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.
Aplicativos cliente públicos executados em dispositivos, como desktop, APIs sem navegador, aplicativos de navegador móvel ou do lado do cliente. Eles não podem ser confiáveis para manter segredos do aplicativo com segurança, portanto, podem acessar apenas APIs Web em nome do usuário. Sempre que o código de origem ou compilado de um determinado aplicativo é transmitido em qualquer lugar em que possa ser lido, desmontado ou inspecionado por partes não confiáveis, ele é um cliente público. Como também oferecem suporte apenas a fluxos de clientes públicos e não podem conter segredos de tempo de configuração, não podem ter segredos de clientes.
Aplicativos cliente confidenciais são executados em servidores, como aplicativos Web, aplicativos de API Web ou aplicativos de serviço/daemon. Eles são considerados difíceis de acessar por usuários ou invasores e, portanto, podem conter adequadamente segredos de tempo de configuração para afirmar a prova de sua identidade. A ID do cliente é exposta por meio do navegador da Web, mas o segredo é transmitido apenas no canal de apoio e nunca exposto diretamente.
Quando você deve habilitar permitir um fluxo de cliente público no registro do aplicativo?
Depois de determinar o tipo de aplicativo cliente que você está criando, você pode decidir se quer habilitar o fluxo de cliente público no registro do aplicativo. Por padrão, permitir fluxo de cliente público no registro do 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/observações |
|---|---|---|
| Autenticação Nativa | Aplicativo de ID externa do 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 de marca. | Observação: a autenticação nativa está disponível apenas para registros de aplicativo 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 de IoT ou uma impressora | |
| Fluxo de credencial de senha de proprietário do recurso | Aplicativos que processam senhas que os usuários inserem diretamente, em vez de redirecioná-los para o site de logon hospedado do Entra e permitir que o Entra processe 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 Integrada do Windows | Aplicativos móveis ou de desktop que são executados no Windows ou em um computador conectado a um domínio do Windows (ingressado no Microsoft Entra ID ou no Microsoft Entra) com o Fluxo de Autenticação Integrada do Windows em vez do gerenciador de contas da Web | Um aplicativo móvel ou de área de trabalho que deve ser conectado automaticamente depois que o usuário entrar no sistema de computadores Windows com uma credencial do Microsoft Entra |
Segredos e a importância deles na prova de identidade
Veja a seguir 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 que se baseiam no Azure têm a opção de descarregar o gerenciamento de segredo, a rotação e a proteção 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 permitir que o provedor lide com a segurança para você.
- ID do cliente e de segredo – Nesse padrão, um par de valores é gerado pelo servidor de autorização ao registrar um cliente. A 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 – PKI (Infraestrutura de Chave Pública), que inclui padrões como X.509, é a tecnologia fundamental que permite a comunicação segura pela Internet e forma o backbone da privacidade da Internet. A PKI é usada para emitir certificados digitais que verificam a identidade das partes envolvidas na comunicação online e é a tecnologia subjacente que alimenta protocolos como HTTPS, que é amplamente usada para proteger o tráfego da Web. Da mesma forma, os certificados podem ser usados para proteger a comunicação S2S (serviço a serviço) no Azure habilitando a autenticação mútua entre os serviços. Isso envolve cada serviço apresentando um certificado para o outro como um meio de provar sua identidade.
- Apresentação de uma declaraçã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 identidade de carga de trabalho pode ser usada para habilitar vários cenários de federação, incluindo o Serviço de Kubernetes do Azure, o Amazon Web Services EKS, o GitHub Actions e muito mais.
Quando é importante a prova de identidade do cliente?
Provar que a 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 confidenciais ou recursos. Alguns exemplos incluem:
- Controlar o acesso à API – Se você tiver uma API limitada (como para cobrança) ou expor dados confidenciais ou recursos, você verificará a identidade do cliente antes de conceder acesso. Por exemplo, isso é importante ao garantir que somente aplicativos autorizados tenham acesso à API, e que o cliente correto seja cobrado pelo uso limitado da API.
- Proteger os usuários contra a representação de aplicativo – Se você tiver um aplicativo implantado no serviço e voltado para o usuário (como um aplicativo da Web orientado por back-end) que acessa dados ou serviços confidenciais, o uso de segredos do cliente para proteger os recursos usados por esse aplicativo poderá impedir que agentes mal-intencionados se passem por um cliente legítimo para fazer phishing com os 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 precisem se comunicar entre si, poderá verificar a identidade de cada serviço para garantir que eles estejam autorizados a acessar somente os recursos necessários para executar sua função.
Em geral, provar que a identidade do cliente é importante quando há a necessidade de autenticar e autorizar um cliente independente ou ao adicionar um usuário.
Clientes confidenciais: melhores práticas para gerenciar segredos
Use identidades gerenciadas para simplificar a implantação e a segurança – Identidades gerenciadas fornecem uma identidade gerenciada automaticamente no Microsoft Entra ID para que os aplicativos usem ao se conectar a recursos que oferecem suporte à autenticação do Microsoft Entra. Os aplicativos podem usar identidades gerenciadas para obter tokens somente do aplicativo Microsoft Entra ID sem ter que 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 melhores práticas a seguir já estão implantadas para você.
Usar segredos de cliente de armazenamento seguro – Armazene em um local seguro, como key vault ou um arquivo de configuração criptografado. Evite armazenar segredos do cliente em texto não criptografado ou como arquivos de check-in em sistemas de controle de versão.
Limitar o acesso – Limitar o acesso a segredos do cliente apenas para funcionários autorizados. Use controle de acesso baseado em função para restringir o acesso a segredos do cliente apenas àqueles que precisam dele para executar as funções operacionais.
Girar segredos do cliente – Rotação de segredos do cliente conforme necessário ou agendado, pode minimizar o risco de um segredo comprometido ser usado para obter acesso não autorizado. Quando aplicado, o período durante o qual uma chave é sugerida para permanecer em uso é influenciado pela força do algoritmo criptográfico usado e/ou pela adesão a padrões ou práticas de conformidade regulatória.
Usar segredos longos e criptografia forte – Bastante relacionado ao ponto anterior, o uso de algoritmos de criptografia fortes para dados em trânsito (no fio) e em repouso (em disco) ajuda a garantir que segredos de alta entropia permaneçam improváveis de serem forçados a brutos. Algoritmos como o AES-128 (ou superior) podem ajudar a proteger dados inativos, enquanto o RSA-2048 (ou superior) pode ajudar a proteger dados com eficiência em trânsito. Devido à natureza em constante evolução da segurança cibernética, é sempre uma melhor prática consultar os especialistas em segurança e revisar periodicamente sua seleção de algoritmos.
Evitar segredos de codificação – Não codificar segredos do cliente no código-fonte. Evitar segredos no código-fonte pode minimizar o valor de atores mal-intencionados que obtêm acesso ao código-fonte. Também pode impedir que esses segredos sejam enviados acidentalmente para repositórios inseguros ou disponibilizados para colaboradores do projeto que poderiam ter acesso de origem, mas não acesso secreto.
Monitorar repositórios de segredos vazados – É um fato lamentável que check-ins ruins ocorram ao lidar com o 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 é um substituto para o monitoramento. O monitoramento automatizado de repositórios pode identificar segredos vazados e, com um plano implementado para alternar credenciais comprometidas, pode ajudar a reduzir incidentes de segurança.
Monitorar atividades suspeitas – Monitore logs e trilhas de auditoria para atividades suspeitas relacionadas a segredos do cliente. Sempre que possível, use alertas automatizados e processos de resposta para notificar a equipe e definir contingências para atividades incomuns relacionadas aos segredos do cliente.
Arquitetar seus aplicativos com sigilo do cliente em mente – Seu modelo de segurança é tão forte quanto o link mais fraco da cadeia. Não encaminhe credenciais de segurança ou tokens de clientes confidenciais para clientes públicos, pois isso poderia mover dados secretos do cliente para um cliente público, permitindo a representação do cliente confidencial.
Usar bibliotecas e SDKs atualizados de fontes confiáveis – a plataforma de identidade da Microsoft fornece vários SDKs de cliente e servidor e middleware projetados para aumentar sua produtividade, mantendo 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 inovações e atualizações de segurança mais recentes.
Comparando os tipos de cliente e seus recursos
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.
- Os dois 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.
- Em MSAL, os aplicativos cliente públicos têm quatro maneiras de adquirir um token, através 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. A ID do cliente é passada uma vez na construção do aplicativo e não precisa ser passada novamente quando o aplicativo adquire um token. Para obter mais informações, consulte adquirindo tokens.
Os clientes públicos são úteis para habilitar o acesso delegado pelo usuário aos recursos protegidos, mas não conseguem provar sua própria identidade de aplicativo. Os clientes confidenciais, por outro lado, podem executar autenticação e autorização de usuário e aplicativo e devem ser criados com 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 de segredos. 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.
Confira também
Para obter mais informações sobre a configuração do aplicativo e a criação de instâncias, confira: