Como é que a aplicação móvel e os serviços web comunicam de forma segura?

Existem 3 formas básicas de gerar tokens e assinaturas utilizadas para autenticar as chamadas de um aplicativo móvel para serviços da Web.

1. O OAuth Core 1.0a

Oauth 1.0a é o mais seguro dos três protocolos comuns. Oauth1 é um protocolo amplamente utilizado, testado, seguro, baseado em assinatura. O protocolo utiliza uma assinatura criptográfica, (geralmente HMAC-SHA1) que combina o segredo token, nonce, e outras informações baseadas em pedidos. A grande vantagem do OAuth 1 é que você nunca passa diretamente o segredo token através do fio, o que elimina completamente a possibilidade de qualquer pessoa ver uma senha em trânsito. Este é o único dos três protocolos que pode ser usado com segurança sem SSL (embora você ainda deva usar SSL se os dados transferidos forem sensíveis). No entanto, este nível de segurança vem com um preço: gerar e validar assinaturas pode ser um processo complexo. Você tem que usar algoritmos de hashing específicos com um conjunto restrito de passos. No entanto, esta complexidade não é mais um problema, pois cada grande linguagem de programação tem uma biblioteca para lidar com isso para você.

2. Auth básico com TLS

A autenticação básica é a mais fácil das três de implementar, pois na maioria das vezes, ela pode ser implementada sem bibliotecas adicionais. Tudo o que é necessário para implementar a autenticação básica está normalmente incluído no seu framework padrão ou biblioteca de idiomas. O problema com a autenticação básica é que ela é, bem "básica", e oferece as mais baixas opções de segurança dos protocolos comuns. Não há opções avançadas para o uso deste protocolo, então você está apenas enviando um nome de usuário e senha que é codificado com base64. A autenticação básica nunca deve ser usada sem criptografia TLS (anteriormente conhecida como SSL) porque a combinação de nome de usuário e senha pode ser facilmente decodificada de outra forma.

3. OAuth 2.0 - OAuth

Oauth2 soa como uma evolução do Oauth1, mas na realidade é uma tomada de autenticação completamente diferente que tenta reduzir a complexidade. A especificação atual de Oauth2 remove assinaturas, então você não precisa mais usar algoritmos criptográficos para criar, gerar, e validar assinaturas. Toda a criptografia é agora tratada por TLS, o que é necessário. Não existem tantas bibliotecas de Oauth2 como existem bibliotecas de Oauth1a, portanto integrar este protocolo na sua API pode ser mais desafiador. O autor principal e editor do padrão Oauth2 renunciou, com este post informativo... Devido a essa instabilidade no comitê de especificação e porque as configurações padrão do OAuth2 são menos seguras que o OAuth1 (sem assinatura digital significa que você não pode verificar se o conteúdo foi adulterado antes ou depois do trânsito), eu recomendo o OAuth1 sobre o OAuth2 para aplicações de dados sensíveis. OAuth2 poderia fazer sentido para ambientes menos sensíveis, como algumas redes sociais.

Obviamente você sempre pode criar sua própria maneira personalizada de gerar este token e assinatura para fazer sua aplicação se comunicar com segurança com seu serviço web. Protocolos de autenticação personalizados devem ser evitados a menos que você realmente, realmente saiba o que você está fazendo e entenda completamente todas as complexidades das assinaturas digitais criptográficas. A maioria das organizações não tem essa experiência, então eu recomendo o OAuth1.0a como uma alternativa sólida.

Or gerar uma API_KEY única para cada usuário como a maioria dos serviços de terceiros (como mailgun).