Autenticar usuários para Confiança Zero

Este artigo ajuda você como desenvolvedor a aprender as práticas recomendadas para autenticar usuários de aplicativos no desenvolvimento de aplicativos de Confiança Zero. Sempre reforce a segurança do seu aplicativo com os princípios de Confiança Zero de privilégio mínimo e verificação explícita.

Tokens de ID na autenticação de usuários

Quando você precisa que um usuário se autentique no seu aplicativo, em vez de coletar um nome de usuário e a senha, o aplicativo pode solicitar um token de identidade (ID). A autenticação de usuários por meio da plataforma de identidade da Microsoft evita riscos de segurança quando o aplicativo retém credenciais de usuário. Quando você solicita tokens de ID, se um agente mal-intencionado violar ou comprometer o aplicativo, não haverá nomes de usuário e senhas, segredos e certificados correspondentes nele.

O token de ID da plataforma de identidade da Microsoft faz parte do padrão OpenID Connect (OIDC), que especifica tokens de ID como Tokens Web JSON (JWT). A cadeia de caracteres longa do JWT compreende três componentes:

1. Declarações de cabeçalho. As declarações de cabeçalho presentes em tokens de ID incluem typ (declaração de tipo), alg (algoritmo para assinar o token) e kid (impressão digital da chave pública para validar a assinatura do token).
2. Declarações de conteúdo. A carga ou corpo (a parte do meio de um token Web JSON) contém uma série de pares de atributos de nome. A norma exige uma reivindicação com o iss (nome do requerente) que vai para o aplicativo que emitiu a reivindicação (o aud, ou reivindicação de audiência).
3. Assinatura. O Microsoft Entra ID gera a assinatura de token que os aplicativos podem usar para validar que o token não foi modificado e que você pode confiar nele.

O exemplo a seguir de um token de ID mostra informações sobre o usuário e confirma a autenticação para utilizar o aplicativo.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "6cb04018-a3f5-46a7-b995-940c78f5aef3",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "00000000-0000-0000-66f3-3332eca7ea81",
  "tid": "3338040d-6c67-4c5b-b112-36a304b66dad",
}.
.[Signature]

Tokens de ID no gerenciamento de acesso

Para receber sua ID de aplicativo (cliente), registre seu aplicativo com a plataforma de identidade da Microsoft. Quando você recebe um token com uma declaração de público (aud) que corresponde à ID do cliente do seu aplicativo, o usuário identificado no token é autenticado no seu aplicativo. Os administradores de TI podem permitir que todos os usuários no locatário usno seu aplicativo. Eles podem permitir que um grupo do qual o usuário é membro utilize seu aplicativo.

Se receber um token cuja declaração de público seja diferente da ID do cliente do seu aplicativo, rejeite imediatamente o token. O usuário não se autenticou entrando no aplicativo. Ele entrou em outro aplicativo. Certifique-se sempre de que o usuário tenha permissão para utilizar seu aplicativo.

Esses detalhes de declarações são importantes na autenticação de usuários:

• Um token da Web JSON é válido até expirar. A declaração exp (expiração) informa quando o token expira. Se a hora atual for anterior à hora na declaração exp, o token é válido.
• Não considere o usuário como autenticado antes do tempo especificado na declaração nbf (não antes do tempo). Os tempos nbf e exp do token definem o tempo de vida válido do token. Quando o tempo de expiração for iminente, certifique-se de obter um novo token de ID.
• sub (declaração de assunto) é um identificador exclusivo para um usuário do aplicativo. O mesmo usuário tem uma reivindicação sub diferente para outros aplicativos. Se quiser armazenar dados para associar novamente a um usuário e impedir que um invasor faça essa associação, utilize a declaração de assunto. Como ela não expõe a identidade do Microsoft Entra do usuário, é a maneira mais privada de associar dados a um usuário. A reinvidicação sub é imutável.
• Se quiser compartilhar informações entre vários aplicativos, utilize a combinação de declarações de ID do locatário (tid) e ID do objeto (oid) que são exclusivas para o usuário. A ID do locatário combinada e a ID do objeto são imutáveis.
• Não importa o que aconteça com a identidade de um indivíduo, as reinvidacações sub, oid e tid permanecem imutáveis. Qualquer coisa sobre o usuário pode mudar, e você ainda pode separar seus dados identificando o usuário com base no assunto ou nas reivindicações tid e oid combinadas.

Autenticação com logon OIDC

Para demonstrar a autenticação do usuário, vamos examinar os aplicativos que usam OIDC para autenticar um usuário. Os mesmos princípios são aplicáveis a aplicativos que usam SAML ou WS-Federation.

Um aplicativo autentica o usuário quando o aplicativo solicita um token de ID da plataforma de identidade da Microsoft. Cargas de trabalho (aplicativos que não têm usuários presentes, mas são executados como serviços, processos em segundo plano, daemons) ignoram essa etapa.

Você deve sempre pedir silenciosamente esse token primeiro. Para adquirir silenciosamente um token nas Bibliotecas de Autenticação da Microsoft (MSAL), seu aplicativo pode começar com o método AcquireTokenSilent. Se o aplicativo puder autenticar sem incomodar o usuário, receberá o token de ID solicitado.

Se a plataforma de identidade da Microsoft não puder concluir a solicitação sem interagir com o usuário, seu aplicativo precisará retornar ao método MSAL AcquireTokenInteractive. Para adquirir interativamente um token, execute a solicitação abrindo uma superfície da Web para um endereço sob o domínio https://login.microsoftonline.com.

A partir dessa superfície da Web, o usuário tem uma conversa privada com a plataforma de identidade da Microsoft. Seu aplicativo não tem exibição dessa conversa nem qualquer controle da conversa. A plataforma de identidade da Microsoft pode solicitar um ID de usuário e senha, autenticação multifator (MFA), autenticação sem senha ou outra interação de autenticação que o administrador de TI ou usuário tenha configurado.

Seu aplicativo receberá um token de ID depois que o usuário tiver executado as etapas de autenticação necessárias. Quando o aplicativo recebe o token, você pode ter certeza de que a plataforma de identidade da Microsoft autenticou o usuário. Se o aplicativo não receber um token de ID, a plataforma de identidade da Microsoft não autenticou o usuário. Não permita que usuários não autenticados continuem em áreas seguras do aplicativo.

É uma prática recomendada para os aplicativos criar uma sessão para um usuário depois que ele recebe um token de ID do Microsoft Entra ID. No token de ID que um aplicativo recebe, uma declaração de expiração (exp) com um carimbo de data/hora Unix. Esse carimbo de data/hora especifica o tempo de expiração dentro ou fora do qual o aplicativo não deve aceitar o JWT para processamento. Utilize esse tempo de expiração do token para direcionar o tempo de vida de suas sessões de usuário. A declaração exp desempenha um papel crucial em manter um usuário explicitamente verificado na frente do aplicativo com o privilégio certo e pela quantidade certa de tempo.

Suporte para Logon único

O logon único (SSO) é uma autenticação que permite aos usuários entrar usando um conjunto de credenciais para vários sistemas de software independentes. O SSO permite que os desenvolvedores de aplicativos não exijam que um usuário entre em cada aplicativo separada e repetidamente. No núcleo do SSO, os desenvolvedores garantem que todos os aplicativos no dispositivo do usuário compartilhem a superfície Web que autentica o usuário. Artefatos na superfície Web (como estado da sessão e cookies) após o SSO da unidade de autenticação bem-sucedida.

Conforme ilustrado no diagrama a seguir, o caso de uso mais simples de uma superfície Web compartilhada é um aplicativo que está sendo executado em um navegador da Web (como Microsoft Edge, Google Chrome, Firefox, Safari). As guias do navegador compartilham o estado do SSO.

Título do diagrama: Navegador da Web – caso mais simples. No centro superior do diagrama, há uma forma de nuvem contendo um ícone de ID do Microsoft Entra. Abaixo da forma da nuvem, há uma caixa. Conectando a forma de nuvem e a caixa há uma linha com uma seta em cada extremidade. O rótulo da caixa é "Mantenha-me conectado: salva cookies de estado SSO em chamadas". Dentro da caixa, no lado esquerdo, há um ícone que se parece com um biscoito. Abaixo do cookie, a legenda é "Conversa privada com o usuário". Abaixo da legenda, há um ícone que representa o usuário. À esquerda desses três componentes, dentro da caixa, há outra caixa. O rótulo da caixa interna é "Guias". Abaixo do rótulo estão quatro caixas quadradas que representam as janelas do navegador em guias.

A plataforma de identidade da Microsoft gerencia o estado SSO em qualquer navegador específico, a menos que o usuário tenha navegadores diferentes abertos no mesmo dispositivo. No Windows 10 e em versões mais recentes, a plataforma de identidade da Microsoft oferece suporte nativo ao SSO do navegador no Internet Explorer e no Microsoft Edge. Quando o usuário faz login no Windows, as acomodações no Google Chrome (por meio da extensão de contas do Windows 10) e no Mozilla Firefox v91+ (por meio de uma configuração do navegador) permitem que cada navegador compartilhe o estado do SSO.

Como mostra o diagrama a seguir, o caso de uso do aplicativo nativo é mais complicado.

Título do diagrama: Aplicativos nativos – navegadores embarcados – sem SSO. No centro superior do diagrama, há uma forma de nuvem contendo um ícone de ID do Microsoft Entra. Na parte inferior do diagrama, estão quatro caixas espalhadas horizontalmente. No canto inferior direito de cada caixa, há um ícone que representa um usuário. Dentro de cada uma das caixas, há uma representação das janelas do navegador, incluindo um ícone de cookie e um ícone de globo. Uma linha com uma seta em cada extremidade conecta cada uma das quatro caixas à forma de nuvem.

Abordagem do corretor de autenticação

Um padrão comum é que cada aplicativo nativo tenha seu próprio WebView incorporado que o impede de participar do SSO. Para resolver esse cenário, o Microsoft Entra ID utiliza uma abordagem de agente de autenticação para aplicativos nativos, conforme ilustrado no diagrama a seguir.

Título do diagrama: Abordagem do agente de autenticação. No centro superior do diagrama, há uma forma de nuvem contendo um ícone de ID do Microsoft Entra. Abaixo da forma de nuvem, há uma forma de retângulo com o rótulo de agente de autenticação. A forma de retângulo contém um ícone de cookie e um de globo. Uma linha com uma seta em cada extremidade conecta a forma de nuvem e a forma de retângulo. Na parte inferior do diagrama, estão quatro caixas espalhadas horizontalmente. No canto inferior direito de cada caixa, há um ícone que representa um usuário. Os ícones em cada caixa representam as janelas do navegador. Uma linha com uma seta em cada extremidade conecta cada uma das quatro caixas à forma de retângulo.

Com um agente de autenticação instalado, os aplicativos enviam solicitações de autenticação ao agente em vez de diretamente à plataforma de identidade da Microsoft. Dessa forma, o agente se torna a superfície compartilhada para toda a autenticação no dispositivo.

Além de fornecer uma superfície compartilhada, o agente de autenticação oferece outros benefícios. Ao adotar o Confiança Zero, as empresas podem querer que os aplicativos sejam executados apenas a partir de dispositivos gerenciados por ela. Exemplos de gerenciamento de dispositivos corporativos incluem Gerenciamento de Dispositivos Móveis (MDM) completo e cenários em que os usuários trazem seus próprios dispositivos que participam do gerenciamento de dispositivo móvel (MAM).

Por padrão, os sistemas operacionais (SO) subjacentes isolam navegadores. Os desenvolvedores precisam de uma conexão mais próxima com o sistema operacional para terem acesso total aos detalhes do dispositivo. No Windows, o agente de autenticação é o Gerenciador de Contas da Web (WAM) do Windows. Em outros dispositivos, o agente de autenticação é o aplicativo Microsoft Authenticator (para dispositivos com iOS ou Android) ou o Aplicativo do Portal da Empresa (para dispositivos com Android). Os aplicativos acessam o agente de autenticação com MSAL. No Windows, um aplicativo pode acessar o WAM sem MSAL. No entanto, o MSAL é a maneira mais fácil para os aplicativos acessarem o agente de autenticação (especialmente aplicativos que não são da Plataforma Universal do Windows).

Os corretores de autenticação trabalham em combinação com o Microsoft Entra ID para utilizar PRT (Primary Refresh Tokens), que reduzem a necessidade de os usuários se autenticarem várias vezes. PRTs podem determinar se o usuário está em um dispositivo gerenciado. O Microsoft Entra ID requer agentes de autenticação, pois introduz tokens de Prova de Posse, uma opção mais segura em relação aos tokens de portador atualmente dominantes.

Próximas etapas

• O artigo Solucionar problemas de tokens de acesso do Microsoft Entra: Validar um token de acesso descreve como, quando você tem um token de acesso do Microsoft Entra, verificar se determinados campos correspondem ao registro.
• A série de artigos Aumentar a resiliência dos aplicativos de autenticação e autorização que você desenvolve discute os aplicativos que usam a plataforma de identidade da Microsoft e o Microsoft Entra ID. Há diretrizes para os aplicativos cliente e de serviço que funcionam em nome de um usuário conectado, bem como aplicativos daemon que funcionam no seu próprio nome. Eles contêm melhores práticas para o uso de tokens, bem como recursos de chamada.
• O artigo Personalizar tokens descreve as informações que você pode receber em tokens do Microsoft Entra e como personalizar esses tokens.
• O artigo Configurar declarações de grupo e funções de aplicativo em tokens mostra como configurar seus aplicativos com definições de função de aplicativo e atribuir grupos de segurança a funções de aplicativos.
• O artigo Criar aplicativos que protegem a identidade por meio de permissões e consentimento fornece uma visão geral das permissões e das práticas recomendadas de acesso.