Melhores práticas e recomendações da plataforma de identidade da Microsoft

Este artigo destaca as melhores práticas, recomendações e supervisões comuns para integração com a plataforma de identidade da Microsoft. Esta lista de verificação orientará você para uma integração segura e de alta qualidade. Revise essa lista regularmente para garantir a manutenção da qualidade e a segurança da integração do seu aplicativo com a plataforma de identidade. A lista de verificação não se destina a examinar todo o aplicativo. O conteúdo da lista de verificação está sujeito a alterações à medida que fizermos melhorias na plataforma.

Se estiver apenas começando, consulte a Documentação da plataforma de identidade da Microsoft para saber mais sobre noções básicas de autenticação, cenários de aplicativos na plataforma de identidade da Microsoft e muito mais.

Use a seguinte lista de verificação para garantir que seu aplicativo seja efetivamente integrado à plataforma de identidade da Microsoft.

Dica

O Assistente de integração pode ajudá-lo a aplicar muitas dessas melhores práticas e recomendações. Selecione qualquer um dos seus registros de aplicativo e, em seguida, selecione o item de menu assistente de integração para começar a usar o assistente.

Noções básicas

Leia e entenda as Políticas de plataforma da Microsoft. Verifique se seu aplicativo segue os termos descritos como foram projetados para proteger os usuários e a plataforma.

Propriedade

Certifique-se de manter as informações associadas à conta que você usou para se registrar e gerenciar aplicativos atualizadas.

Consolidação da marca

Adote as Diretrizes de identidade visual para aplicativos.

Dê ao seu aplicativo um nome e um logotipo significativos. Essas informações aparecem no prompt de consentimento do seu aplicativo. Certifique-se de que seu nome e logotipo sejam representativos da sua empresa/produto para que os usuários possam tomar decisões com conhecimento. Certifique-se de que você não está violando marcas comerciais.

Privacidade

Forneça links para a declaração de privacidade e os termos de serviço do aplicativo.

Segurança

Gerenciar seus URIs de redirecionamento:

• Mantenha a propriedade de todos os URIs de redirecionamento e mantenha os registros DNS deles atualizados.
• Não use caracteres curinga (*) em seus URIs.
• Para aplicativo Web, verifique se todos os URIs estão seguros e criptografados (por exemplo, usando esquemas https).
• Para clientes públicos, use URIs de redirecionamento específicos da plataforma, se aplicável (principalmente para iOS e Android). Caso contrário, use URIs de redirecionamento com uma grande quantidade de aleatoriedade para evitar colisões ao retornar para seu aplicativo.
• Se seu aplicativo estiver sendo usado a partir de um agente Web isolado, você poderá usar https://login.microsoftonline.com/common/oauth2/nativeclient.
• Examine e remova regularmente todos os URIs de redirecionamento não usados ou desnecessários.

Se seu aplicativo estiver registrado em um diretório, minimize e monitore manualmente a lista de proprietários de registro de aplicativo.

Não habilite o suporte para o fluxo de concessão implícita do OAuth2, a não ser que isso seja explicitamente solicitado. Saiba mais sobre o cenário válido aqui.

Vá além do nome de usuário/senha. Não use o fluxo de credenciais de senha do proprietário do recurso (ROPC), que lida diretamente com as senhas dos usuários. Esse fluxo requer um alto grau de confiança e exposição do usuário, e só deverá ser usado quando outros fluxos mais seguros não puderem ser usados. Esse fluxo ainda é necessário em alguns cenários (como DevOps), mas lembre-se de que seu uso imporá restrições ao aplicativo. Para abordagens mais modernas, leia Fluxos de autenticação e cenários de aplicativos.

Proteja e gerencie as credenciais confidenciais do aplicativo para aplicativos Web, APIs Web e aplicativos daemon. Use credenciais de certificado, em vez de credenciais de senha (segredos do cliente). Se você precisar usar uma credencial de senha, não a defina manualmente. Não armazene credenciais no código ou na configuração e nunca permita que elas sejam manipuladas por seres humanos. Se possível, use identidades gerenciadas para recursos do Azure ou Azure Key Vault para armazenar e girar suas credenciais regularmente.

Certifique-se de que o aplicativo solicite permissões de privilégio mínimo. Solicite apenas permissões que seu aplicativo precisa, e somente quando você precisar delas. Entender os diferentes tipos de permissões. Use permissões de aplicativo somente se necessário; use permissões delegadas sempre que possível. Para obter uma lista completa de permissões de Microsoft Graph, consulte esta referência de permissões.

Se você estiver protegendo uma API com a plataforma de identidade da Microsoft, pense cuidadosamente nas permissões que ela deve expor. Considere qual é a granularidade certa para sua solução e qual(ais) permissão(ões) exige(m) o consentimento do administrador. Verifique as permissões esperadas nos tokens de entrada antes de tomar decisões de autorização.

Implementação

Use soluções de autenticação modernas (OAuth 2.0, OpenID Connect) para fazer o logon dos usuários com segurança.

Não programe diretamente em protocolos como OAuth 2.0 e Open ID. Em vez disso, aproveite a Biblioteca de Autenticação da Microsoft (MSAL). As bibliotecas MSAL encapsulam com segurança protocolos de segurança em uma biblioteca fácil de usar e você obtém suporte interno para cenários de Acesso condicional, logon único (SSO)de todo o dispositivo e suporte interno a cache de tokens. Para obter mais informações, consulte a lista de bibliotecas de clientecom suporte da Microsoft. Se você precisar codificar manualmente os protocolos de autenticação, deverá seguir o SDL da Microsoft ou a metodologia de desenvolvimento semelhante. Preste muita atenção às considerações de segurança nas especificações de padrões para cada protocolo.

Migre os aplicativos existentes da ADAL (Biblioteca de Autenticação do Azure Active Directory) para a Biblioteca de Autenticação da Microsoft. A MSAL é a mais recente solução de plataforma de identidade da Microsoft e está disponível em .NET, JavaScript, Android, iOS, macOS, Python e Java. Leia mais sobre como migrar aplicativos ADAL.NET, ADAL.jse ADAL.NET e iOS broker.

Para aplicativos móveis, configure cada plataforma usando a experiência de registro de aplicativo. Para que seu aplicativo aproveite o Microsoft Authenticator ou o Portal da Empresa Microsoft para logon único, ele precisa de um "URI de redirecionamento do agente" configurado. Isso permite que a Microsoft retorne o controle para seu aplicativo após a autenticação. Ao configurar cada plataforma, a experiência de registro do aplicativo orientará você pelo processo. Use o guia de início rápido para baixar um exemplo de trabalho. No iOS, use agentes e modo de exibição da Web do sistema sempre que possível.

Em aplicativos Web ou APIs Web, mantenha um cache de token por conta. Para aplicativos Web, o cache de token deve ser codificado pela ID da conta. Para as APIs Web, a conta deve ser codificada pelo hash do token usado para chamar a API. A MSAL.NET fornece serialização de cache de token personalizado no .NET e no .NET Framework. Por motivos de segurança e desempenho, nossa recomendação é serializar um cache por usuário. Para obter mais informações, leia sobre serialização de cache de token.

Se seu aplicativo precisar de dados que são disponibilizados por meio do Microsoft Graph, solicite permissões para eles com o ponto de extremidade do Microsoft Graph em vez da API individual.

Não veja nem tente analisar o valor do token de acesso como um cliente. Eles podem alterar valores, formatos ou até mesmo serem criptografados sem aviso-sempre use a id_token se o cliente precisar aprender algo sobre o usuário ou chamar Microsoft Graph. Somente as APIs da Web devem analisar os tokens de acesso (já que são aqueles que definem o formato e as chaves de criptografia).

Experiência do usuário final

Entenda a experiência de consentimento e configure as partes do prompt de consentimento do aplicativo para que os usuários finais e os administradores tenham informações suficientes para determinar a confiança no aplicativo.

Minimize o número de vezes que um usuário precisa inserir as credenciais de logon durante o uso do aplicativo através da autenticação silenciosa (aquisição silenciosa de token) antes dos fluxos interativos.

Não use "prompt=consent" para todas as entradas. Use prompt=consent somente se você determinou que precisa pedir consentimento para permissões adicionais (por exemplo, se você alterou as permissões necessárias do aplicativo).

Quando aplicável, enriqueça o aplicativo com os dados do usuário. Usar a API de Microsoft Graph é uma maneira fácil de fazer isso. A ferramenta Graph Explorer pode ajudá-lo a começar.

Registre o conjunto completo de permissões necessárias para o aplicativo a fim de que os administradores possam conceder consentimento facilmente ao locatário. Use o consentimento incremental em tempo de execução para ajudar os usuários a entender por que seu aplicativo está solicitando permissões que podem preocupar ou confundir os usuários quando solicitado na primeira inicialização.

Implemente uma experiência simplificada de logon único. É um requisito de privacidade e segurança, além de proporcionar uma boa experiência ao usuário.

Testando

Teste se as Políticas de Acesso Condicional que podem afetar a capacidade dos usuários de usar o aplicativo.

Teste o aplicativo com todas as contas possíveis as quais você planeja oferecer suporte (por exemplo, contas corporativas ou escolares, contas pessoais da Microsoft, contas infantis e contas soberanas).

Recursos adicionais

Explore informações detalhadas sobre a v2.0:

• Plataforma de identidade da Microsoft (visão geral)
• Referência de protocolos da plataforma de identidade da Microsoft
• Referência de tokens de acesso
• Referência de tokens de ID
• Referência de bibliotecas de autenticação
• Permissões e consentimento na plataforma de identidade da Microsoft
• API do Microsoft Graph