Esclarecimento: Mobile App = Native App
Conforme declarado em outros comentários e em algumas fontes online, implícito parece ser um ajuste natural para aplicativos móveis, no entanto, a melhor solução nem sempre é clara (e, de fato, implícito não é recomendado pelos motivos discutidos abaixo).
Práticas recomendadas de app nativo OAuth2
Seja qual for a abordagem que você escolher (existem algumas desvantagens a serem consideradas), você deve prestar atenção às práticas recomendadas descritas aqui para aplicativos nativos usando OAuth2: https://tools.ietf.org/html/rfc8252
Considere as seguintes opções
Implícito
Devo usar implícito?
Para citar a Seção 8.2 https://tools.ietf.org/html/rfc8252#section-8.2
O fluxo de autorização de concessão implícita do OAuth 2.0 (definido na Seção 4.2 do OAuth 2.0 [RFC6749]) geralmente funciona com a prática de realizar a solicitação de autorização no navegador e receber a resposta de autorização por meio de comunicação entre aplicativos baseada em URI.
No entanto, como o fluxo implícito não pode ser protegido por PKCE [RFC7636] (que é exigido na Seção 8.1), o uso do fluxo implícito com aplicativos nativos NÃO É RECOMENDADO .
Os tokens de acesso concedidos por meio do fluxo implícito também não podem ser atualizados sem a interação do usuário, tornando o fluxo de concessão do código de autorização - que pode emitir tokens de atualização - a opção mais prática para autorizações de aplicativos nativos que exigem a atualização dos tokens de acesso.
Código de autorização
Se você optar pelo Código de autorização, uma abordagem seria usar o proxy por meio de seu próprio componente de servidor da web, o que enriquece as solicitações de token com o segredo do cliente para evitar armazená-lo no aplicativo distribuído nos dispositivos.
Trecho abaixo de: https://dev.fitbit.com/docs/oauth2/
O fluxo de Concessão do Código de Autorização é recomendado para aplicativos que possuem um serviço da web. Esse fluxo requer comunicação de servidor para servidor usando o segredo do cliente de um aplicativo.
Nota: Nunca coloque o segredo do seu cliente em código distribuído, como aplicativos baixados por meio de uma loja de aplicativos ou JavaScript do lado do cliente.
Os aplicativos que não têm um serviço da web devem usar o fluxo de concessão implícita.
Conclusão
A decisão final deve levar em consideração sua experiência de usuário desejada, mas também seu apetite por risco, após fazer uma avaliação de risco adequada das abordagens selecionadas e compreender melhor as implicações.
Uma ótima leitura está aqui https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
Outro é https://www.oauth.com/oauth2-servers/oauth-native-apps/ que afirma
A melhor prática atual da indústria é usar o Fluxo de Autorização omitindo o segredo do cliente e usar um agente de usuário externo para concluir o fluxo. Um agente de usuário externo normalmente é o navegador nativo do dispositivo (com um domínio de segurança separado do aplicativo nativo) para que o aplicativo não possa acessar o armazenamento de cookies ou inspecionar ou modificar o conteúdo da página dentro do navegador.
Consideração PKCE
Você também deve considerar o PKCE, que é descrito aqui https://www.oauth.com/oauth2-servers/pkce/
Especificamente, se você também estiver implementando o Authorization Server, https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ declara que você deve
- Permite que os clientes registrem esquemas de URL personalizados para seus URLs de redirecionamento.
- Oferece suporte a URLs de redirecionamento de IP de loopback com números de porta arbitrários para oferecer suporte a aplicativos de desktop.
- Não presuma que os aplicativos nativos podem manter um segredo. Exigir que todos os aplicativos declarem se são públicos ou confidenciais e apenas emitir segredos do cliente para aplicativos confidenciais.
- Oferece suporte à extensão PKCE e exige que os clientes públicos a utilizem.
- Tente detectar quando a interface de autorização é incorporada na visualização da web de um aplicativo nativo, em vez de iniciada em um navegador do sistema, e rejeite essas solicitações.
Consideração de visualizações da web
Existem muitos exemplos de uso de Web Views, ou seja, um agente de usuário incorporado, mas essa abordagem deve ser evitada (especialmente quando o aplicativo não é original) e, em alguns casos, pode resultar na proibição de usar uma API como trecho abaixo a partir daqui demonstra
Qualquer tentativa de incorporar a página de autenticação do OAuth 2.0 resultará no banimento do seu aplicativo da API Fitbit.
Por questões de segurança, a página de autorização do OAuth 2.0 deve ser apresentada em uma visualização de navegador dedicada. Os usuários do Fitbit só podem confirmar que estão se autenticando no site Fitbit.com genuíno se tiverem as ferramentas fornecidas pelo navegador, como a barra de URL e as informações do certificado Transport Layer Security (TLS).
Para aplicativos nativos, isso significa que a página de autorização deve ser aberta no navegador padrão. Os aplicativos nativos podem usar esquemas de URL personalizados como URIs de redirecionamento para redirecionar o usuário de volta do navegador para o aplicativo que está solicitando permissão.
Os aplicativos iOS podem usar a classe SFSafariViewController em vez de alternar para o Safari. O uso da classe WKWebView ou UIWebView é proibido.
Os aplicativos Android podem usar as guias personalizadas do Chrome em vez de alternar para o navegador padrão. O uso de WebView é proibido.
Para esclarecer ainda mais, aqui está uma citação desta seção de um rascunho anterior do link de melhores práticas fornecido acima
Os agentes de usuário incorporados, comumente implementados com visualizações da web, são um método alternativo para autorizar aplicativos nativos. No entanto, eles não são seguros para uso por terceiros, por definição. Eles envolvem o login do usuário com suas credenciais de login completas, apenas para ter seu escopo reduzido para credenciais OAuth menos potentes.
Mesmo quando usados por aplicativos próprios confiáveis, os agentes de usuário incorporados violam o princípio do menor privilégio ao obter credenciais mais poderosas do que precisam, aumentando potencialmente a superfície de ataque.
Em implementações típicas baseadas em visualização da web de agentes de usuário incorporados, o aplicativo host pode: registrar todas as teclas digitadas no formulário para capturar nomes de usuários e senhas; enviar formulários automaticamente e ignorar o consentimento do usuário; copie os cookies de sessão e use-os para executar ações autenticadas como o usuário.
Incentivar os usuários a inserir credenciais em uma visualização da web incorporada sem a barra de endereço usual e outros recursos de identidade que os navegadores têm torna impossível para o usuário saber se está acessando o site legítimo e, mesmo quando está, isso os treina que não há problema em inserir credenciais sem validar o site primeiro.
Além das questões de segurança, as visualizações da web não compartilham o estado de autenticação com outros aplicativos ou o navegador do sistema, exigindo que o usuário faça login para cada solicitação de autorização e levando a uma experiência do usuário ruim.
Devido ao acima exposto, o uso de agentes de usuário incorporados NÃO É RECOMENDADO, exceto quando um aplicativo primário confiável atua como o agente de usuário externo para outros aplicativos ou fornece logon único para vários aplicativos próprios.
Os servidores de autorização DEVEM considerar tomar medidas para detectar e bloquear logins por meio de user-agents incorporados que não sejam seus, quando possível.
Alguns pontos interessantes também são levantados aqui: /security/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- uma