Noções básicas sobre o fluxo de concessão implícita OAuth2 no Azure Active Directory (AD)

A concessão implícita OAuth2 é notória por ser a concessão com a lista mais longa de preocupações de segurança na especificação OAuth2. No entanto, essa é a abordagem implementada pelo ADAL JS e a que recomendamos ao escrever aplicativos SPA. O que acontece? É tudo uma questão de compensações: e, como se vê, a concessão implícita é a melhor abordagem que você pode buscar para aplicativos que consomem uma API Web por meio de JavaScript de um navegador.

O que é a concessão implícita OAuth2?

A autorização de código OAuth2 mais representativa é o protocolo de autorização que utiliza dois endpoints distintos. O endpoint de autorização é usado para a fase de interação do usuário, o que resulta em um código de autorização. O endpoint de token é então usado pelo cliente para trocar o código por um token de acesso e, frequentemente, um token de atualização também. Os aplicativos Web devem apresentar suas próprias credenciais de aplicativo ao terminal de token, para que o servidor de autorização possa autenticar o cliente.

O de concessão implícita OAuth2 é uma variante de outras concessões de autorização. Ele permite que um cliente obtenha um token de acesso (e id_token, ao usar o OpenId Connect) diretamente do ponto de extremidade de autorização, sem entrar em contato com o ponto de extremidade do token nem autenticar o cliente. Essa variante foi projetada para aplicativos baseados em JavaScript em execução em um navegador da Web: na especificação original do OAuth2, os tokens são retornados em um fragmento de URI. Isso disponibiliza os bits de token para o código JavaScript no cliente, mas garante que eles não serão incluídos em redirecionamentos para o servidor. Na concessão implícita do OAuth2, o endpoint de autorização emite tokens de acesso diretamente ao cliente por meio de um URI de redirecionamento que foi previamente fornecido. Ele também tem a vantagem de eliminar a necessidade de chamadas entre origens diferentes, o que é necessário se o aplicativo JavaScript precisar contatar o endpoint do token.

Uma característica importante da concessão implícita OAuth2 é o fato de que esses fluxos nunca retornam tokens de atualização para o cliente. A próxima seção mostra como isso não é necessário e, de fato, seria um problema de segurança.

Cenários adequados para a concessão implícita OAuth2

A especificação OAuth2 declara que a concessão implícita foi criada para habilitar aplicativos de agente de usuário, ou seja, aplicativos JavaScript em execução em um navegador. A característica de definição desses aplicativos é que o código JavaScript é usado para acessar recursos de servidor (normalmente uma API Web) e para atualizar a experiência do usuário do aplicativo adequadamente. Pense em aplicativos como Gmail ou Outlook Web Access: quando você seleciona uma mensagem na caixa de entrada, apenas o painel de visualização de mensagens é alterado para exibir a nova seleção, enquanto o restante da página permanece não modificado. Essa característica contrasta com os aplicativos Web tradicionais baseados em redirecionamento, em que cada interação do usuário resulta em um postback completo e uma renderização completa da nova resposta do servidor.

Os aplicativos que usam a abordagem baseada em JavaScript ao extremo são chamados de aplicativos de página única ou SPAs. A ideia é que esses aplicativos atendam apenas a uma página HTML inicial e ao JavaScript associado, com todas as interações subsequentes sendo controladas por chamadas de API Web executadas por meio do JavaScript. No entanto, abordagens híbridas, em que o aplicativo é basicamente controlado por postback, mas executa chamadas JS ocasionais, não são incomuns . A discussão sobre o uso de fluxo implícito também é relevante para elas.

Aplicativos baseados em redirecionamento normalmente protegem suas solicitações por meio de cookies, no entanto, essa abordagem não funciona tão bem para aplicativos JavaScript. Os cookies só funcionam no domínio para o qual foram gerados, enquanto as chamadas JavaScript podem ser direcionadas para outros domínios. Na verdade, esse será frequentemente o caso: pense em aplicativos invocando a API do Microsoft Graph, a API do Office, a API do Azure – todos que residem fora do domínio de onde o aplicativo é atendido. Uma tendência crescente para aplicativos JavaScript é não ter nenhum back-end, contando com 100% em APIs Web de terceiros para implementar sua função de negócios.

Atualmente, o método preferencial de proteção de chamadas para uma API Web é usar a abordagem de token de portador OAuth2, em que cada chamada é acompanhada por um token de acesso OAuth2. A API Web examina o token de acesso de entrada e, se encontrar nele os escopos necessários, concederá acesso à operação solicitada. O fluxo implícito fornece um mecanismo conveniente para aplicativos JavaScript obterem tokens de acesso para uma API Web, oferecendo inúmeras vantagens em relação aos cookies:

• Os tokens podem ser obtidos de forma confiável sem a necessidade de chamadas entre origens – o registro obrigatório do URI de redirecionamento garante o retorno dos tokens, assegurando que eles não sejam desviados.
• Os aplicativos JavaScript podem obter quantos tokens de acesso forem necessários, para quantas APIs Web forem direcionadas, sem nenhuma restrição aos domínios
• Recursos do HTML5, como armazenamento de sessão ou local, concedem controle total sobre o armazenamento de token e o gerenciamento da duração, enquanto o gerenciamento de cookies é opaco para o aplicativo.
• Os tokens de acesso não são suscetíveis a ataques de falsificação de solicitação entre sites (CSRF)

O fluxo de concessão implícita não emite tokens de atualização, principalmente por motivos de segurança. Um token de atualização não tem um escopo tão restrito quanto os tokens de acesso, concedendo muito mais energia, causando muito mais danos caso seja vazado. No fluxo implícito, os tokens são entregues na URL, portanto, o risco de interceptação é maior do que na concessão de código de autorização.

No entanto, um aplicativo JavaScript tem outro mecanismo à sua disposição para renovar tokens de acesso sem solicitar repetidamente credenciais ao usuário. O aplicativo pode usar um iframe oculto para executar novas solicitações de token no ponto de extremidade de autorização do Azure AD: desde que o navegador ainda tenha uma sessão ativa (leia-se: tem um cookie de sessão) no domínio do Azure AD, a solicitação de autenticação poderá ocorrer com êxito sem qualquer necessidade de interação do usuário.

Esse modelo concede ao aplicativo JavaScript a capacidade de renovar os tokens de acesso de forma independente e até mesmo adquirir novos para uma nova API (desde que o usuário tenha consentido anteriormente com eles). Isso evita a carga adicional de adquirir, manter e proteger um artefato de alto valor, como um token de atualização. O artefato que possibilita a renovação silenciosa, o cookie de sessão do Azure AD, é gerenciado fora do aplicativo. Outra vantagem dessa abordagem é que um usuário pode sair do Azure AD usando qualquer um dos aplicativos conectados ao Azure AD, em execução em qualquer uma das guias do navegador. Isso resulta na exclusão do cookie de sessão do Azure AD e o aplicativo JavaScript perderá automaticamente a capacidade de renovar tokens para o usuário desconectado.

A concessão implícita é adequada para meu aplicativo?

A concessão implícita apresenta mais riscos do que outras concessões e as áreas às quais você precisa prestar atenção estão bem documentadas (por exemplo, uso indevido do token de acesso para representar o proprietário do recurso em fluxo implícito e considerações sobre o modelo de ameaça e segurança do OAuth 2.0). No entanto, o perfil de risco mais alto deve-se, em grande parte, ao fato de que ele destina-se a habilitar aplicativos que executam código ativo, servidos por um recurso remoto para um navegador. Se você estiver planejando uma arquitetura SPA, não tiver componentes de back-end ou pretender invocar uma API Web via JavaScript, é recomendável usar o fluxo implícito para aquisição de token.

Se o aplicativo for um cliente nativo, o fluxo implícito não é a melhor escolha. A ausência do cookie de sessão do Azure AD no contexto de um cliente nativo priva seu aplicativo dos meios de manter uma sessão de longa duração. O que significa que seu aplicativo solicitará repetidamente ao usuário ao tentar obter tokens de acesso para novos recursos.

Se você estiver desenvolvendo um aplicativo Web que inclui um back-end e consumindo uma API de seu código de back-end, o fluxo implícito também não será uma boa opção. Outros subsídios lhe dão muito mais poder. Por exemplo, a concessão de credenciais do cliente OAuth2 fornece a capacidade de obter tokens que refletem as permissões atribuídas ao próprio aplicativo, em oposição às delegações de usuário. Isso significa que o cliente tem a capacidade de manter o acesso programático aos recursos mesmo quando um usuário não está ativamente envolvido em uma sessão e assim por diante. Não só isso, mas essas concessões dão garantias de segurança mais altas. Por exemplo, os tokens de acesso nunca transitam pelo navegador do usuário, eles não correm o risco de serem salvos no histórico do navegador e assim por diante. O aplicativo cliente também pode executar autenticação forte ao solicitar um token.

Próximas etapas

• Veja como integrar um aplicativo ao Azure AD para obter mais profundidade sobre o processo de integração de aplicativos.