Partilhar via

Gerenciar tokens para Zero Trust

  • Artigo

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

Certifique-se de que seu aplicativo siga o princípio Zero Trust de menor privilégio e impeça o uso de maneiras que comprometam sua intenção. Limite o acesso do usuário com Just-In-Time e Just-Enough-Access (JIT/JEA), políticas adaptativas baseadas em risco e proteção de dados. Separe as seções sensíveis 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 em seu aplicativo.

Crie o mínimo de privilégios em como seu aplicativo gerencia tokens de ID que ele recebe da plataforma de identidade da Microsoft. As informações nos ID Tokens permitem verificar se um usuário é quem afirma 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.

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

Usar declarações de token em seus aplicativos

Use declarações em tokens de ID para UX dentro do seu aplicativo, como chaves em um banco de dados e fornecendo acesso ao aplicativo cliente. O token de ID é a extensão principal que o OpenID Connect (OIDC) faz 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 use 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 do usuário que incluem o seguinte.

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

Seus aplicativos podem usar o openid escopo para solicitar um token de ID da plataforma de identidade da Microsoft. O padrão OIDC rege o openid escopo juntamente com o formato e o conteúdo do token de ID. O OIDC especifica estes escopos:

  • Use o openid escopo para entrar no usuário e adicionar uma sub declaração ao token de ID. Esses escopos fornecem um ID de usuário que é exclusivo para o aplicativo e o usuário e chama o ponto de extremidade UserInfo.
  • O email escopo adiciona uma email declaração contendo o endereço de e-mail do usuário ao token de ID.
  • O profile escopo adiciona declarações com atributos de perfil básicos do usuário (nome, nome de usuário) ao token de ID.
  • O offline_access escopo 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 openid, email e profile escopos a cada solicitação de token. Como resultado, o MSAL sempre retorna um token de ID e um token de acesso em cada chamada para AcquireTokenSilent ou AcquireTokenInteractive. A MSAL sempre solicita o offline_access escopo. A plataforma de identidade da Microsoft sempre retorna offline_access o escopo, mesmo quando o aplicativo solicitante não especifica o offline_access escopo.

A Microsoft usa 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 precisa acessar um recurso que o Microsoft Entra ID protege, ele deve usar um escopo que o recurso definiu.

Por exemplo, o Microsoft Graph define o User.Read escopo 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 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.

Gerenciar tempos de vida de token

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 de usuário determina 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 exp sessão deve ser baseado na declaração no token de ID. A exp declaração é o momento em que o token de ID expira e o tempo após o qual você não pode mais usar o token para autenticar o usuário.

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

Em geral, os tokens devem ser válidos e não expirados. A declaração de audiência (aud) deve corresponder ao seu ID de 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 nbf declarações (não antes) e ( exp expiração) para garantir que o tempo atual esteja dentro dos valores dessas duas reivindicações.

Não tenha como objetivo períodos de sessão excepcionalmente longos ou curtos. Deixe que o tempo de vida 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 maiores do que as políticas ditadas pelo provedor de identidade.

Armazenar em cache e atualizar tokens

Lembre-se de armazenar tokens em cache adequadamente. O MSAL armazena tokens automaticamente em cache, mas os tokens têm tempo de vida. Use tokens durante toda a sua vida útil e armazene-os em cache adequadamente. Se você pedir repetidamente o mesmo token, a limitação fará com que seu aplicativo se torne menos responsivo. Se o seu aplicativo abusar da emissão de tokens, 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 você não estiver usando o MSAL, certifique-se de que sua biblioteca de escolha faça uso efetivo de tokens de atualização.

Quando o 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 token de acesso/atualização depois que o token de acesso atual expirar. Use tokens de atualização para adquirir tokens de acesso extra para outros recursos. Os tokens de atualização são vinculados a uma combinação de usuário e cliente (não a um recurso ou 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ões.

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 seja interrompido quando a plataforma de identidade da Microsoft emitir tokens criptografados.

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

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

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

No seu código, verifique se há classes de erro em vez de casos de erro individuais. Por exemplo, manipule a interação do usuário necessária em vez de erros individuais quando o sistema não conceder permissão. Como você pode perder esses casos individuais, é melhor verificar se há 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 e AcquireTokenInteractive fornecer contestações de declarações que a AcquireTokenSilent chamada exige. Isso garante um gerenciamento eficaz da solicitação interativa.

Próximos passos