Autenticar usuários para Zero Trust

Este artigo ajuda você, como desenvolvedor, a aprender as práticas recomendadas para autenticar os usuários do aplicativo no desenvolvimento de aplicativos Zero Trust. Sempre melhore a segurança do seu aplicativo com os princípios Zero Trust de menor privilégio e verifique explicitamente.

Tokens de ID na autenticação do usuário

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

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

1. Declarações de cabeçalho. As declarações de cabeçalho presentes nos tokens de ID incluem typ (declaração de tipo), alg (algoritmo para assinar o token) e kid (impressão digital para a chave pública para validar a assinatura do token).
2. Declarações de carga útil. A carga útil ou o corpo (a parte do meio de um token da Web JSON) contém uma série de pares de atributos de nome. O padrão exige que haja uma declaração com o (nome do iss emissor) que vai para o aplicativo que foi emitido o token (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 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 usar 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": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
}.
.[Signature]

Tokens de ID no gerenciamento de acesso

Para receber sua ID de aplicativo (cliente), registre seu aplicativo na plataforma de identidade da Microsoft. Quando você recebe um token com uma declaração de audiência (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 do locatário usem seu aplicativo. Eles podem permitir que um grupo do qual o usuário é membro use seu aplicativo.

Se você receber um token cuja declaração de audiência seja diferente da ID do cliente do seu aplicativo, rejeite imediatamente o token. O utilizador não está autenticado na sua aplicação porque iniciou sessão noutra aplicação. Certifique-se sempre de que o utilizador tem permissão para utilizar a sua aplicação.

Estes detalhes de declarações são importantes na autenticação do usuário:

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

Autenticação com OIDC

Para demonstrar a autenticação do usuário, vamos examinar os aplicativos que usam o OIDC para autenticar um usuário. Os mesmos princípios se aplicam a aplicativos que usam SAML (Security Assertion Markup Language) ou WS-Federation.

Um aplicativo autentica o usuário quando o aplicativo solicita um token de ID da plataforma de identidade da Microsoft. As 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 esta etapa.

Você deve sempre pedir este token em silêncio primeiro. Para adquirir silenciosamente um token nas Bibliotecas de Autenticação da Microsoft (MSAL), seu aplicativo pode começar com o AcquireTokenSilent método. Se seu aplicativo puder se autenticar sem incomodar o usuário, ele 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 um token interativamente, execute a solicitação abrindo uma superfície da Web para um endereço sob o https://login.microsoftonline.com domínio.

A partir desta superfície web, o usuário tem uma conversa privada com a plataforma de identidade da Microsoft. Seu aplicativo não tem visualização dessa conversa, nem tem 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 configurada pelo administrador de TI ou usuário.

Seu aplicativo receberá um token de ID depois que o usuário executar as etapas de autenticação necessárias. Quando seu aplicativo recebe o token, você pode ter certeza de que a plataforma de identidade da Microsoft autenticou o usuário. Se seu 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 seu 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. Este carimbo de data/hora especifica o tempo de expiração ativado ou após o qual o aplicativo não deve aceitar o JWT para processamento. Use esse tempo de expiração de token para direcionar o tempo de vida de suas sessões de usuário. A exp reivindicação desempenha um papel crucial em manter um usuário explicitamente verificado na frente do aplicativo com o privilégio certo e pelo tempo certo.

Suporte para Logon Único

A autenticação de logon único (SSO) permite que os usuários entrem com um conjunto de credenciais em 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 separadamente e repetidamente. No núcleo do SSO, os desenvolvedores garantem que todos os aplicativos no dispositivo do usuário compartilhem a superfície da Web que autentica o usuário. Artefatos na superfície da Web (como estado da sessão e cookies) após o SSO da unidade de autenticação bem-sucedida.

Como ilustrado no diagrama a seguir, o caso de uso mais simples de uma superfície da 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 de SSO.

Título do diagrama: Navegador da Web – caso mais simples. Aparecendo no centro superior do diagrama está uma forma de nuvem contendo um ícone de ID do Microsoft Entra. Abaixo da forma da nuvem há uma caixa. Conectando a forma da nuvem e a caixa é uma linha com uma seta em cada extremidade. O rótulo da caixa é "Mantenha-me conectado, salva cookies de estado SSO em invocações". Dentro da caixa, no lado esquerdo, há um ícone que se parece com um cookie. Abaixo do cookie, a legenda é "Conversa privada com o usuário". Abaixo da legenda há um ícone que representa o usuário. À esquerda destes três componentes, dentro da caixa, está 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 de SSO em qualquer navegador específico, a menos que o usuário tenha navegadores diferentes abertos no mesmo dispositivo. No Windows 10 e versões mais recentes, a plataforma de identidade da Microsoft suporta nativamente o SSO do navegador Microsoft Edge. Quando o utilizador inicia sessão no Windows, as acomodações no Google Chrome (através da extensão de contas do Windows 10) e no Mozilla Firefox v91+ (através de uma definição do navegador) permitem que cada navegador partilhe o estado SSO do próprio Windows.

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

Título do diagrama: Aplicações nativas – navegadores incorporados – sem SSO. Aparecendo no centro superior do diagrama está 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. Conectando cada uma das quatro caixas à forma de nuvem há uma linha com uma seta em cada extremidade.

Abordagem do corretor de autenticação

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

Título do diagrama: Auth broker approach. Aparecendo no centro superior do diagrama está uma forma de nuvem contendo um ícone de ID do Microsoft Entra. Abaixo da forma da nuvem há uma forma de retângulo com o rótulo, Auth Broker. A forma do retângulo contém um ícone de cookie e um ícone de globo. Conectando a forma da nuvem e a forma do retângulo há uma linha com uma seta em cada extremidade. 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. Conectando cada uma das quatro caixas à forma de retângulo há uma linha com uma seta em cada extremidade.

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

Além de fornecer uma superfície compartilhada, o corretor de autenticação oferece outros benefícios. Ao adotar o Zero Trust, as empresas podem querer que os aplicativos sejam executados apenas a partir de dispositivos gerenciados pela empresa. Exemplos de gerenciamento de dispositivos corporativos incluem o 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 Aplicativos Móveis (MAM).

Por design, os sistemas operacionais (SO) subjacentes isolam os navegadores. Os desenvolvedores precisam de uma conexão mais próxima com o sistema operacional para ter acesso total aos detalhes do dispositivo. No Windows, o agente de autenticação é o Windows Web Account Manager (WAM). Em outros dispositivos, o agente de autenticação é o aplicativo Microsoft Authenticator (para dispositivos que executam iOS ou Android) ou o Aplicativo do Portal da Empresa (para dispositivos que executam 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 de os aplicativos acessarem o agente de autenticação (especialmente aplicativos que não são aplicativos da Plataforma Universal do Windows).

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

Próximos passos

• 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, verifica se determinados campos correspondem ao registro.
• Aumente a resiliência dos aplicativos de autenticação e autorização que você desenvolve em série, aborda aplicativos que usam a plataforma de identidade da Microsoft e o Microsoft Entra ID. Eles incluem orientação para aplicativos cliente e de serviço que funcionam em nome de um usuário conectado e aplicativos daemon que funcionam em seu próprio nome. Eles contêm práticas recomendadas para usar tokens e recursos de chamada.
• Personalizar tokens descreve as informações que você pode receber nos tokens do Microsoft Entra e como você pode personalizar os tokens.
• 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 aplicativo.
• 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.