iOS e Server: estratégia OAuth

6

Estou tentando trabalhar como lidar com a autenticação quando tenho clientes iOS acessando um servidor Node.js e quero usar serviços como Google, Facebook, etc. para fornecer autenticação básica para meu aplicativo. Minha ideia atual de um fluxo típico é esta:

  1. O usuário toca no botão Facebook / Google, que aciona as caixas de diálogo do OAuth (2) e autentica o usuário no dispositivo. Neste ponto, o dispositivo tem o token de acesso dos usuários. Este token é salvo para que, na próxima vez que o usuário usar o aplicativo, ele possa ser recuperado.

  2. O token de acesso é transmitido para o meu servidor Node.js, que o armazena, e o marca como não verificado.

  3. O servidor verifica o token fazendo uma chamada para o Facebook / google para o endereço de e-mail do usuário. Se isso funcionar, o token é sinalizado como verificado e o servidor sabe que tem um usuário verificado. Se o Facebook / google não conseguir autenticar o token, o servidor informa ao cliente iOS para autenticar novamente e apresentar um novo token.

  4. O cliente iOS agora pode acessar as chamadas api no meu servidor Node.js passando o token a cada vez. Desde que o token corresponda ao token armazenado e verificado, o servidor aceita a chamada.

Obviamente, os tokens têm limites de tempo. Eu suspeito que é possível, mas altamente improvável que alguém possa cheirar um token de acesso e tentar usá-lo em sua vida útil, mas fora isso espero que este seja um método razoavelmente seguro para verificação de usuários em clientes iOS sem ter que rolar meu própria segurança.

Todas as opiniões e conselhos são bem-vindos.

    
por drekka 25.06.2012 / 03:31
fonte

1 resposta

8

Sim, alguém pode ver esse token no pacote, e é por isso que é recomendável usar a criptografia SSL de todo o tráfego de rede antes e depois da autenticação e distribuição de um token.

Alguém em uma rede sem fio não criptografada, como em um Starbucks, usa esse método o tempo todo para pegar pacotes para serviços como o Facebook que não exigem tráfego criptografado por SSL. Eles podem usar esse token em suas próprias solicitações para falsificar outra sessão de usuários.

Da mesma forma, se eu for um hacker e comprometer uma determinada máquina atrás de um firewall pelo qual passa o tráfego da rede, digamos um balanceador de carga, posso usar essas informações para determinar credenciais e tokens de sessão no tráfego não criptografado que passa por .

A maneira apropriada de lidar com isso é utilizar a criptografia SSL, mesmo que seja um certificado auto-assinado, então você está certo de que terceiros não podem escutar as solicitações dos usuários.

    
por 25.06.2012 / 04:28
fonte