Compartilhar via

Gerenciar tokens para Zero Trust

  • Artigo

No desenvolvimento de aplicativos com Confiança Zero, é importante definir especificamente a intenção do aplicativo e seus requisitos de acesso a recursos. Seu aplicativo deve solicitar apenas o acesso necessário para funcionar conforme o esperado. Este artigo ajuda você, como desenvolvedor, a criar segurança nos aplicativos com tokens de ID, tokens de acesso e tokens de segurança que os aplicativos podem receber da plataforma de identidade da Microsoft.

Certifique-se de que o aplicativo siga o princípio de Confiança Zero de privilégios mínimos e impeça o uso que possa vir a comprometer sua intenção. Limite o acesso do usuário com JIT/JEA (Just-In-Time e Just-Enough-Access), políticas adaptáveis baseadas em risco e proteção de dados. Separe as seções confidenciais e poderosas do seu aplicativo, fornecendo apenas acesso de usuário autorizado a essas áreas. Limite os usuários que podem usar seu aplicativo e os recursos que eles têm no seu aplicativo.

Crie privilégios mínimos em como seu aplicativo gerencia tokens de ID que ele recebe da plataforma de identidade da Microsoft. As informações nos Tokens de ID permitem que você verifique se um usuário é quem ele diz ser. O usuário ou sua organização pode especificar condições de autenticação, como fornecer uma MFA, usar um dispositivo gerenciado e estar no local correto.

Facilite para seus clientes o gerenciamento de autorizações para seu aplicativo. Reduza a sobrecarga de provisão do usuário e a necessidade de processos manuais. O provisionamento automático de usuários permite que administradores de TI automatizem a criação, manutenção e remoção de identidades de usuários em repositórios de identidades de destino. Seus clientes podem basear automações em alterações em usuários e grupos com o provisionamento de aplicativos ou o provisionamento orientado por RH no Microsoft Entra ID.

Use declarações de token em seus aplicativos

Use declarações em tokens de ID para UX em seu aplicativo, como chaves em um banco de dados e fornecendo acesso ao aplicativo cliente. O token de ID é a extensão principal do OpenID Connect (OIDC) para o OAuth 2.0. Seu aplicativo pode receber tokens de ID ao lado ou em vez de tokens de acesso.

No padrão padrão para autorização de token de segurança, um token de ID emitido permite que o aplicativo receba informações sobre o usuário. Não utilize o token de ID como um processo de autorização para acessar recursos. O servidor de autorização emite tokens de ID que contêm declarações com informações de usuário que incluem o seguinte.

  • A declaração de público-alvo (aud) é a ID do cliente do seu aplicativo. Aceite apenas tokens para sua ID de cliente de API.
  • A declaração tid é a ID do locatário que emitiu o token. A declaração oid é um valor imutável que identifica exclusivamente o usuário. Utilize a combinação exclusiva de declarações tid e oid como chave quando precisar associar dados ao usuário. É possível usar esses valores de declaração para conectar seus dados de volta à ID do usuário no Microsoft Entra ID.
  • A declaração sub é um valor imutável que identifica exclusivamente o usuário. A reivindicação de assunto também é exclusiva para o seu aplicativo. Se você utilizar a declaração sub para associar dados ao usuário, será impossível conectá-los a um usuário no Microsoft Entra ID.

Seus aplicativos podem utilizar o escopo openid para solicitar um token de ID da plataforma de identidade da Microsoft. O padrão OIDC controla o escopo openid com o formato e o conteúdo do token de ID. O OIDC especifica os seguintes escopos:

  • Utilize o escopo openid para entrar no usuário e adicionar uma declaração sub ao token de ID. Esses escopos fornecem uma ID de usuário exclusiva para o aplicativo e o usuário e que chama o ponto de extremidade UserInfo.
  • O escopo email adiciona uma declaração email contendo o endereço de e-mail do usuário ao token de ID.
  • O escopo profile adiciona declarações com atributos de perfil básicos do usuário (nome, nome de usuário) ao token de ID.
  • O escopo offline_access permite que o aplicativo acesse os dados do usuário mesmo quando o usuário não está presente.

A Biblioteca de Autenticação da Microsoft (MSAL) sempre adiciona os escopos openid, email e profile a cada solicitação de token. Como resultado, a MSAL sempre retorna um token de ID e um token de acesso em cada chamada para AcquireTokenSilent ou AcquireTokenInteractive. A MSAL sempre solicita o escopo offline_access. A plataforma de identidade da Microsoft sempre retorna o escopo offline_access mesmo quando o aplicativo solicitante não especifica o escopo offline_access.

A Microsoft utiliza o padrão OAuth2 para emitir tokens de acesso. O padrão OAuth2 diz que você recebe um token, mas não especifica o formato do token ou o que precisa estar no token. Quando seu aplicativo precisar acessar um recurso protegido pelo Microsoft Entra ID, ele deverá usar um escopo definido pelo recurso.

Por exemplo, o Microsoft Graph define o escopo User.Read que autoriza o aplicativo a acessar o perfil completo do usuário atual e o nome do locatário. O Microsoft Graph define permissões em toda a gama de funcionalidades disponíveis nessa API.

Após a autorização, a plataforma de identidade da Microsoft retorna um token de acesso ao seu aplicativo. Quando você chama o recurso, seu aplicativo fornece esse token como parte do cabeçalho de autorização da solicitação HTTP para a API.

Gerencie a vida útil dos tokens

Os aplicativos podem criar uma sessão para um usuário depois que a autenticação for concluída com êxito com o Microsoft Entra ID. O gerenciamento de sessão do usuário direciona a frequência com que um usuário precisa de reautenticação. Seu papel em manter um usuário explicitamente verificado na frente do aplicativo com o privilégio certo e pela quantidade certa de tempo é crucial. O tempo de vida da sessão deve ser baseado na declaração exp no token de ID. A declaração exp é a hora em que o token de ID expira e a hora após a qual não é mais possível utilizar esse token para autenticar o usuário.

Sempre respeite a vida útil do token, fornecida na resposta do token para tokens de acesso ou a declaração exp no token de ID. As condições que regem o tempo de vida do token podem incluir a frequência de entrada de uma empresa. Seu aplicativo não pode configurar o tempo de vida do token. Não é possível solicitar uma vida útil do token.

Em geral, os tokens devem ser válidos e não expirados. A declaração de público (aud) deve corresponder ao ID do cliente. Verifique se o token vem de um emissor confiável. Se você tiver uma API multilocatário, poderá optar por filtrar para que apenas locatários específicos possam chamar sua API. Certifique-se de impor o tempo de vida do token. Verifique as declarações nbf (não antes) e exp (expiração) para garantir que a hora atual esteja dentro dos valores dessas duas declarações.

Não almeje sessões excepcionalmente longas ou curtas. Deixe que a vida útil do token de ID concedido conduza essa decisão. Manter as sessões do seu aplicativo ativas além da validade do token viola as regras, políticas e preocupações que levaram um administrador de TI a definir uma duração de validade do token para impedir o acesso não autorizado. Sessões curtas degradam a experiência do usuário e não necessariamente aumentam a postura de segurança. Estruturas populares como ASP.NET permitem que você defina tempos limite de sessão e cookie a partir do tempo de expiração do token de ID do Microsoft Entra ID. Seguir o tempo de expiração do token do provedor de identidade garante que as sessões do usuário nunca sejam mais longas do que as políticas ditadas pelo provedor de identidade.

Cache e tokens de atualização

Lembre-se de armazenar os tokens em cache adequadamente. O MSAL armazena tokens em cache automaticamente, mas os tokens têm vida útil. Utilize tokens durante toda a vida útil e armazene-os adequadamente em cache. Se você pedir repetidamente o mesmo token, a limitação fará com que seu aplicativo se torne menos responsivo. Se seu aplicativo abutilizar da emissão de token, o tempo necessário para emitir novos tokens para seu aplicativo aumentará.

As bibliotecas MSAL gerenciam os detalhes do protocolo OAuth2, incluindo a mecânica de atualização de tokens. Se não estiver utilizando a MSAL, certifique-se de que sua biblioteca de escolha use tokens de atualização de maneira eficaz.

Quando seu cliente adquire um token de acesso para acessar um recurso protegido, ele recebe um token de atualização. Use o token de atualização para obter novos pares de tokens de acesso/atualização depois que o token de acesso atual expira. Use tokens de atualização para adquirir tokens de acesso extras para outros recursos. Os tokens de atualização são associados a uma combinação de usuário e cliente (não a um recurso nem a um locatário). Você pode usar um token de atualização para adquirir tokens de acesso em qualquer combinação de recurso e locatário em que seu aplicativo tenha permissão.

Gerenciar erros e bugs de token

Seu aplicativo nunca deve tentar validar, decodificar, inspecionar, interpretar ou examinar o conteúdo de um token de acesso. Essas operações são estritamente de responsabilidade da API de recursos. Se seu aplicativo tentar examinar o conteúdo de um token de acesso, é altamente provável que seu aplicativo quebre quando a plataforma de identidade da Microsoft emite tokens criptografados.

Raramente, uma chamada para recuperar um token pode falhar devido a problemas como falha ou interrupção da rede, infraestrutura ou serviço de autenticação. Aumente a resiliência da experiência de autenticação no seu aplicativo se ocorrer uma falha de aquisição de token seguindo estas práticas recomendadas:

  • Armazene em cache localmente e proteja tokens com criptografia.
  • Não passe artefatos de segurança como tokens em canais não seguros.
  • Compreenda e aja com base em exceções e respostas de serviço do provedor de identidade.

Os desenvolvedores geralmente têm dúvidas sobre como procurar dentro de tokens para depurar problemas, como receber um erro 401 ao chamar o recurso. À medida que mais tokens criptografados impedem que você olhe dentro de um token de acesso, você precisa encontrar alternativas para olhar dentro dos tokens de acesso. Para depuração, a resposta do token que contém o token de acesso fornece as informações necessárias.

Em seu código, verifique se há classes de erro em vez de casos de erro individuais. Por exemplo, lide com a interação necessária do usuário em vez de erros individuais quando o sistema não concede permissão. Como você pode perder esses casos individuais, é melhor verificar um classificador como a interação do usuário, em vez de se aprofundar em códigos de erro individuais.

Talvez seja necessário recorrer a AcquireTokenInteractive e fornecer contestações de sinistros exigidas pela chamada AcquireTokenSilent. Isso garante o gerenciamento eficaz da solicitação interativa.

Próximas etapas