Desenvolvendo a estratégia de permissões delegadas

  • Artigo

Este artigo ajudará você, como desenvolvedor, a implementar a melhor abordagem para gerenciar permissões em seu aplicativo e desenvolver usando os princípios da Confiança Zero. Conforme descrito em Adquirir autorização para acessar recursos, permissões delegadas são usadas com acesso delegado para permitir que um aplicativo atue em nome de um usuário, acessando apenas o que esse usuário pode acessar. Permissões de aplicativos são usadas com acesso direto para permitir que um aplicativo acesse todos os dados aos quais essa permissão está associada. Apenas administradores e proprietários de entidades de segurança podem consentir com as permissões de aplicativos.

Os modelos de permissão e consentimento referem-se principalmente a um aplicativo. O processo de permissão e consentimento não tem controle sobre o que um usuário pode fazer. Ele controla quais ações o aplicativo tem permissão para executar.

Consulte o diagrama de Venn a seguir. Com permissões delegadas, há uma interseção entre o que o usuário tem permissão para fazer e o que o aplicativo tem permissão para fazer. Essa interseção é a permissão efetiva pela qual o aplicativo está vinculado. Sempre que você utiliza uma permissão delegada, ela é limitada pelas permissões efetivas.

O diagrama Venn mostra permissões efetivas como interseção de permissões de aplicativo e recursos de usuário.

Por exemplo, seu aplicativo que tem usuários na frente do aplicativo obtém permissão para atualizar o perfil de cada usuário no locatário. Isso não significa que qualquer pessoa executando seu aplicativo possa atualizar o perfil de outra pessoa. Se o administrador decidir conceder User.ReadWrite.All ao seu aplicativo, ele acredita que esse aplicativo esteja fazendo a coisa certa ao atualizar o perfil de qualquer usuário. Seu aplicativo pode registrar as alterações e proteger adequadamente as informações. O administrador faz um juízo de valor sobre o aplicativo, não sobre o usuário.

Abordagem de privilégios mínimos

APIs podem ser complexas. APIs simples podem não ter muitas operações. APIs complexas como o Microsoft Graph encapsulam muitas solicitações que um aplicativo pode querer utilizar. Só porque o aplicativo tem o direito de ler não significa que ele deve ter o direito de atualizar. Por exemplo, o Microsoft Graph tem milhares de APIs. Só porque você tem permissão para ler o perfil do usuário, não há razão para que você também tenha permissão para excluir todos os arquivos do OneDrive.

Como desenvolvedor, você deve:

  • saiba quais APIs o aplicativo chama.
  • entender a documentação da API e quais permissões a API requer.
  • Utilize a menor permissão possível para realizar suas tarefas.

As APIs geralmente fornecem acesso a armazenamentos de dados da organização e atraem a atenção de invasores que desejam acessar esses dados.

Avaliar as permissões solicitadas para garantir que você busque o conjunto com o mínimo absoluto de privilégios para fazer o trabalho. Evite solicitar permissões de privilégios mais altos; em vez disso, trabalhe cuidadosamente com o grande número de permissões que APIs como o Microsoft Graph fornecem. Localize e utilize as permissões mínimas para atender às suas necessidades. Se você não escrever código para atualizar o perfil do usuário, não o solicitará para seu aplicativo. Se você acessar apenas usuários e grupos, não solicitará acesso a outras informações no diretório. Você não solicitará permissão para gerenciar o email do usuário se não escrever o código que acessa o email do usuário.

No desenvolvimento de aplicativos Confiança Zero:

  • Defina a intenção do seu aplicativo e o que ele precisa.
  • Certifique-se de que os agentes mal-intencionados não podem comprometer e utilizar seu aplicativo de uma maneira que você não pretendia.
  • Faça solicitações de aprovação nas quais você define seus requisitos (por exemplo, leia o e-mail do usuário).

As pessoas que podem aprovar suas solicitações se enquadram em duas categorias: administradores que sempre podem consentir com solicitações de permissão e usuários regulares que não são administradores. No entanto, os administradores de locatários têm a palavra final no seu locatário sobre quais permissões exigem consentimento do administrador e para quais permissões um usuário pode consentir.

Quando um designer de API requer o consentimento do administrador para uma permissão, essa permissão sempre exigirá o consentimento do administrador; Um administrador de locatário não pode anular isso e exigir apenas o consentimento do usuário.

Quando um designer de API define permissões que exigem o consentimento do usuário, as sugestões de consentimento do usuário pelo designer de API podem ser anuladas pelo administrador do locatário. Os administradores do locatário podem fazer isso com uma "grande mudança" no locatário: tudo requer o consentimento do administrador. Eles podem anular o consentimento do usuário de uma maneira mais granular com o gerenciamento de permissão e consentimento. Por exemplo, podem permitir que os usuários concordem com solicitações de consentimento de usuários de fornecedores verificados, mas não de outros fornecedores. Em outro exemplo, podem permitir que User.Read conecte o usuário e leia seu perfil, mas requer consentimento do administrador para aplicativos que solicitam permissão para emails ou arquivos.

Os designers de API fazna suas sugestões, mas os administradores de locatários têm a palavra final. Portanto, como desenvolvedor, você nem sempre saberá quando seu aplicativo requer o consentimento do administrador. É bom planejar e projetar em torno disso, mas lembre-se, quando você faz uma solicitação de token, ela pode ser negada por qualquer motivo. Em seu código, você precisa lidar normalmente com a não obtenção de um token porque os administradores de locatários nos quais seus clientes ou usuários estão executando seu aplicativo decidem quando as permissões exigem o consentimento do administrador.

Exemplo utilizando JavaScript MSAL

Para a autenticação neste exemplo, você utilizará nossa Biblioteca de Autenticação Microsoft (MSAL) JavaScript para entrar no usuário em um aplicativo de página única (SPA) onde toda a lógica do aplicativo é executada a partir do navegador.

No Artigo de início rápido relacionado, você pode baixar e executar um exemplo de código. Ele demonstra como um SPA (aplicativo de página única) JavaScript pode conectar usuários e chamar o Microsoft Graph usando o fluxo de código de autorização com chave de prova para troca de código (PKCE). O exemplo de código demonstra como obter um token de acesso para chamar a API do Microsoft Graph ou qualquer API Web.

Como mostrado no código de exemplo abaixo, você instanciará um cliente público porque um aplicativo que é executado inteiramente no navegador deve ser um cliente público. O usuário pode colocar as mãos nos elementos internos do seu aplicativo quando o código estiver no navegador.

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

Então você utilizará nossa biblioteca MSAL. No MSAL JavaScript, há uma API específica para entrar. Há duas APIs que utilizam recursos específicos no navegador. Uma delas é entrar com uma experiência pop-up; A outra é entrar com uma experiência de redirecionamento do navegador.

Como mostra o exemplo de código abaixo, o pop-up de login trata da autenticação que o usuário precisa realizar chamando a função signIn.

function signIn() {

    /**
     * You can pass a custom request object below. This will override the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

Seu aplicativo pode obter informações sobre o usuário, como seu nome para exibição ou ID de usuário. Em seguida, seu aplicativo precisa de autorização para ler o perfil completo do usuário do Microsoft Graph seguindo um padrão que você utilizará em nossas bibliotecas MSAL.

Como mostra o código de exemplo abaixo, seu aplicativo tenta obter a autorização chamando AcquireTokenSilent. Se o Microsoft Entra ID puder emitir o token sem interagir com o usuário, AcquireTokenSilent retornará o token necessário para seu aplicativo acessar o Microsoft Graph em nome do usuário.

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            if (error instanceof msal.InteractionRequiredAuthError) {
                // fallback to interaction when silent call fails
                return myMSALObj.`AcquireTokenPopup`(request)
                    .then(tokenResponse => {
                        console.log(tokenResponse);
                        return tokenResponse;
                    }).catch(error => {
                        console.error(error);
                    });
            } else {
                console.warn(error);
            }
    });
}

No entanto, muitas vezes o Microsoft Entra ID não pode emitir o token sem interagir com o usuário (por exemplo, o usuário alterou sua senha ou não concedeu consentimento). Portanto, AcquireTokenSilent retornará um erro ao aplicativo, pois requer interação do usuário. Quando seu aplicativo receber o erro, você voltará a chamar AcquireTokenPopup.

Nesse ponto, o Microsoft Entra ID terá uma conversa com o usuário para que ele possa autenticar o usuário e autorizar seu aplicativo a agir em nome do usuário (por exemplo, fazer uma MFA, fornecer sua senha, conceder consentimento). Em seguida, seu aplicativo receberá o token necessário para avançar.

Uma etapa principal na jornada de uma empresa para o Confiança Zero é adotar métodos de autenticação mais fortes em vez de apenas um ID de usuário e senha. O código de exemplo descrito acima permite totalmente que uma empresa mude para o método de autenticação mais forte que a empresa escolher. Por exemplo, autenticação multifator, totalmente sem senha com uma chave FIDO2, Microsoft Authenticator.

Próximas etapas