Como proteger o acesso à API em aplicativos móveis

Quando uma organização fornece aplicações móveis como parte dos seus serviços digitais, os requisitos de segurança nem sempre são compreendidos. Aqui estão alguns problemas e soluções comuns a serem considerados ao integrar aplicativos móveis com APIs seguras. Com esse conhecimento, você pode evitar erros dispendiosos e ativar os comportamentos de segurança mais atualizados em seus aplicativos.

Evite a segurança que prioriza a autenticação

Os aplicativos móveis devem chamar APIs para interagir com dados seguros. Essas APIs precisam receber uma credencial em uma solicitação de API antes de concederem acesso. A credencial deve identificar o usuário que está interagindo com o aplicativo, para que esse usuário esteja autenticado.

Existem muitas soluções de autenticação por aí, e os desenvolvedores são frequentemente incentivados a integrar métodos de autenticação específicos em seus aplicativos. Por exemplo, os provedores de login social podem permitir uma solução de autenticação rápida com uma experiência de usuário de login moderna.

Mesmo assim, é provável que o desenvolvedor tenha problemas ao chamar APIs. Após o login, o provedor de login social pode emitir uma credencial de mensagem de API chamada token de acesso ao aplicativo. No entanto, se o aplicativo enviar esse token para suas APIs, ele será rejeitado. Eu chamo isso de problema do “token de acesso estrangeiro”.

Alguns desenvolvedores podem contornar isso emitindo tokens separados de endpoints de API. No entanto, esta abordagem tem uma série de preocupações de segurança, uma vez que o token pode ter características de segurança erradas, como permitir demasiado acesso à API ou ter uma vida útil demasiado longa. Mais importante ainda, as partes interessadas em segurança e conformidade da sua organização devem ter visibilidade do aplicativo móvel e da segurança da API e devem ser capazes de controlar esses fatores ao longo do tempo.

Use a segurança API-First

Uma opção melhor é usar uma abordagem API-first, onde você projeta APIs antes de codificar o front-end ou o back-end. Isso deve incluir o design da credencial da mensagem API que será enviada do aplicativo móvel. Esse tipo de abordagem é fundamental para a estrutura de autorização do OAuth 2.0. Para usar o OAuth, você deve introduzir um novo componente, o servidor de autorização, que emite tokens de acesso que os clientes, como aplicativos móveis, podem enviar para APIs.

Seu aplicativo móvel executa então um fluxo de código usando os padrões OAuth 2.0 e OpenID Connect. As práticas recomendadas específicas para dispositivos móveis são explicadas na especificação RFC 8252 – OAuth para aplicativos nativos. Um fluxo atualizado é ilustrado abaixo, com a mesma experiência de login do usuário que a abordagem de autenticação inicial. Quando o provedor de login social emite tokens, o servidor de autorização os valida e depois emite seus próprios tokens. A principal diferença é que as APIs agora confiam nesses tokens, uma vez que são emitidos pelo servidor de autorização.

Usar o OAuth traz grandes benefícios:

• Você pode criar tokens de acesso com limites de segurança de API usando escopos.
• Você pode criar tokens de acesso com o mínimo de privilégios de API usando declarações.
• Você pode projetar tokens de acesso para terem vida útil curta, caso um deles seja roubado.
• O servidor de autorização fornece visibilidade dos comportamentos de segurança às partes interessadas.
• Seu aplicativo pode ser atualizado para usar qualquer método de autenticação sem alterações de código.
• Tanto os aplicativos móveis quanto as APIs terceirizam a difícil funcionalidade de segurança para o servidor de autorização.

Proteja-se contra a representação de aplicativos

Ao seguir as instruções na RFC 8252, você abre uma instância do navegador do sistema móvel para autenticar o usuário. A maneira mais simples de implementar um fluxo de código móvel é receber a resposta de autorização usando um URI de redirecionamento de esquema de uso privado, como com.example.app:/callback. No entanto, os sistemas operacionais móveis permitem que vários aplicativos se associem ao mesmo esquema. Isso abre uma ameaça: um aplicativo malicioso pode se passar por seu aplicativo e roubar tokens usando o OAuth do seu aplicativo client_id e redirect_uri parâmetros em seu próprio fluxo de código.

A melhor solução baseada em padrões OAuth é usar um URI de redirecionamento de esquema HTTPS reivindicado. Um exemplo seria https://app.example.com//callback. Esses URLs HTTPS usam o suporte da plataforma móvel para links diretos HTTPS. Para retornar a resposta de autorização ao aplicativo, um App Link é invocado no Android ou um Universal Link no iOS. Para que isso funcione, você deve hospedar um arquivo de ativos de link direto no domínio da Internet HTTPS, que associa o certificado de assinatura de código do seu aplicativo ao domínio. No momento da instalação, a plataforma móvel valida essa associação e só permite que o aplicativo use o URL de link direto quando a validação for bem-sucedida. Isso evita que um aplicativo malicioso use o URI de redirecionamento para receber tokens.

No entanto, há aborrecimentos nesta abordagem. A resposta de autorização é retornada em uma resposta de redirecionamento, e o navegador móvel pode não permitir que um link direto seja invocado automaticamente após um redirecionamento, fazendo com que o navegador móvel apresente uma página Não Encontrado. Uma técnica para superar esse problema é alterar o URI de redirecionamento para uma página da Web intermediária hospedada on-line em um domínio da Web separado. Esta página da web pode renderizar um botão continuar e, quando o usuário clicar nele, a página da web pode executar JavaScript para encaminhar a resposta de autorização ao aplicativo usando um link direto.

No entanto, os aplicativos móveis têm uma maneira melhor de proteger contra a falsificação de identidade: usando os recursos de atestado integrados à maioria dos dispositivos móveis modernos. O atestado permite que o aplicativo genuíno crie uma assinatura criptográfica que uma parte mal-intencionada não poderia produzir, que pode então ser verificada por um componente do servidor. Você pode introduzir lógica de atestado em seus fluxos OAuth. Atualmente, talvez seja necessário considerar uma pequena minoria de dispositivos que não suportam atestação, embora estes devam desaparecer com o tempo.

Proteja-se contra roubo de token

Você também deve tomar medidas para impedir que terceiros não autorizados usem os tokens de acesso do seu aplicativo móvel. Na maioria dos casos de uso móvel da Internet, esses são tokens de portador, portanto, se um invasor interceptar um token de acesso de alguma forma, o invasor poderá enviá-lo para suas APIs. Você limita o impacto desse tipo de exploração projetando tokens de acesso com privilégios mínimos e de curta duração.

Um cliente móvel é mais comumente um cliente público que adquire tokens do servidor de autorização sem uma credencial de cliente. Ao executar um fluxo de código, você deve usar a Chave de Prova para Troca de Código (PKCE) para criar um segredo de tempo de execução chamado verificador de código que protege a emissão inicial de tokens. Você poderá então receber um token de acesso com duração de 15 minutos, bem como um token de atualização cujo tempo de vida representa o tempo da sessão autenticada do usuário.

O token de atualização é usado para obter novos tokens de acesso para garantir que não haja impacto na usabilidade quando os tokens de acesso expirarem. No entanto, se um token de atualização for interceptado de alguma forma, um invasor poderá facilmente enviá-lo ao seu servidor de autorização para obter um token de acesso para usar em suas APIs. Uma proteção parcial é o uso de tokens de atualização de uso único que invalidam quaisquer outros tokens de atualização para a mesma sessão do usuário.

Idealmente, você também deve ser capaz de proteger o token de atualização de forma mais robusta. Uma maneira possível de implementar um fluxo de token de atualização reforçado pode ser basear uma solução no atestado. Neste exemplo, o aplicativo móvel interage com uma API de atestado, como Google Play Integrity API ou Apple App Attest. O aplicativo envia uma solicitação de atestado para provar sua identidade e recebe uma prova de atestado que uma parte mal-intencionada não poderia fornecer. Essa prova é então enviada ao endpoint do token do servidor de autorização. O servidor de autorização então executa uma lógica customizada para validar a prova antes de aceitar o token de atualização:

Uma proteção de token mais avançada é possível em alguns casos de uso. Por exemplo, se você controlar dispositivos, poderá usar uma solução de gerenciamento de dispositivos para provisionar cada dispositivo com um certificado de cliente distinto. Isso permitiria que instâncias do aplicativo móvel atuassem como clientes OAuth confidenciais, onde o certificado do cliente é usado em todas as solicitações para obter tokens. Isso permite atualizar de tokens ao portador para tokens de acesso vinculados a certificados.

Planeje a autenticação nativa

Quando um aplicativo protegido por OAuth executa um fluxo de código, ele pode usar as opções integradas do seu servidor de autorização, que podem incluir opções de segurança fortes, como chaves de acesso e carteiras digitais. Alguns servidores de autorização também fornecem um sistema de plug-in. Isso permite implementar qualquer método de autenticação personalizado cuja lógica você possa projetar. Se necessário, você pode encadeá-los em um fluxo de trabalho de autenticação multifator.

Os aplicativos móveis protegidos por OAuth implementam logins usando o navegador do sistema por padrão. No entanto, em muitos casos de uso móvel, isso pode não ser o que você deseja. Há muitas maneiras pelas quais recursos nativos do dispositivo, que podem estar indisponíveis no navegador, podem autenticar usuários.

Considere este exemplo de fluxo nativo, conforme ilustrado abaixo: Uma organização fornece um aplicativo de quiosque que as lojas usam para enviar dados às APIs sobre as transações dos membros. Um usuário apresenta um código QR para comunicar dados de um aplicativo de adesão executado em seu dispositivo pessoal para o aplicativo de quiosque. Os dados incluem uma prova que é enviada ao servidor de autorização da organização, onde é verificada. Um token de acesso é então emitido para o aplicativo de quiosque para suas comunicações de API subsequentes.

Para que isso funcionasse, o fluxo de código executado pelo aplicativo móvel precisaria funcionar de maneira diferente do normal. Por padrão, o navegador móvel executa um fluxo de trabalho de solicitações HTTP de autenticação e o navegador renderiza telas de autenticação baseadas em HTML. Em vez disso, o OAuth móvel nativo poderia usar um fluxo de trabalho de solicitações de API de autenticação, e o aplicativo móvel usaria dados de resposta para renderizar telas nativas.

Espero que os novos comportamentos de segurança móvel sejam integrados aos padrões OAuth aprimorados para aplicativos móveis nos próximos anos. Você poderá então contar com melhorias de segurança nativas, como atestado, e usar os métodos de autenticação nativos mais recentes. Até que os padrões sejam melhorados, os provedores de servidores de autorização provavelmente implementarão soluções personalizadas, como a API de autenticação hipermídia (HAAPI) fornecida pela Curity.

Conclusão

Ao projetar segurança para aplicativos móveis que chamam APIs, comece com as credenciais de mensagem da API que o aplicativo enviará às APIs. Em seguida, certifique-se de que os logins móveis permitam que o aplicativo use essa credencial. Além disso, considere as ameaças cibernéticas e como você irá mitigá-las. Procure acertar o design de segurança de ponta a ponta o mais cedo possível para evitar erros dispendiosos.

Ao usar a estrutura de autorização OAuth 2.0 e um servidor de autorização com os recursos certos, você pode implementar sua segurança móvel para API, gerando muitos benefícios:

• A complexidade da segurança é terceirizada de seus aplicativos e APIs.
• Os tokens de acesso podem ser projetados de forma a minimizar a exploração de dados.
• Seus aplicativos móveis podem integrar os métodos de autenticação mais atualizados.
• Suas equipes podem seguir um ecossistema de práticas recomendadas.
• Seu servidor de autorização permite que você mantenha sua segurança atualizada.

A postagem Como proteger o acesso à API em aplicativos móveis apareceu pela primeira vez em The New Stack.