[SP-pm] Autenticação REST

[Marcelo Milhomem]

Enviar o ID do usuário em toda requisição é ruim, ele acaba sendo redundante e fazendo par com o token.

O token é uma string única, randômica e temporária associada a um usuário e persistida em algum database. É enviado em toda requisição através de header normalmente. É uma pratica bem comum e viável.

A questão do certificado no client é uma coisa que quero muito fazer a um tempo, mas realmente temos poucas ferramentas prontas, temos que fazer. O Renato falou que o HTTPS já faz isso e ficou a impressão de que isso seria uma camada a mais e não é, ele é o próprio SSL do HTTPS, você só muda as chaves que estão em jogo.

A grande vantagem disso é que não precisa ter um banco de dados central de tokens, ou um controlador de autenticação que deve ser consultado a cada requisição. O client não mandaria mais um token e sim sua identificação confiável por qualquer servidor HTTP que consiga resolver SSL. Você só precisaria distribuir nesses servidores uma chave CA.

Com essa abordagem a quantidade de requisições em banco de dados pode cair pela metade e tira da sua arquitetura o ponto único de falha. Um tópico importante citado por outros é que o seu método de autenticação tem que ser suportado largamente e esse método é nativo para os Browsers e muito bem documentado, eu só vi algumas limitações no mundo Mobile quando se tenta usar um Certificado auto-assinado.

Abs,

> On Mar 1, 2015, at 11:46 PM, Eduardo Almeida <eduardo at web2solutions.com.br> wrote:
> 
> On 3/1/15 11:34 PM, Eduardo Almeida wrote:
>> O user autentica o client uma primeira vez e recebe um token para as consecutivas requisições feita á API. Tokens expiram. É lógico que você pode definir a vida útil deles de acordo com sua necessidade.
> Dá para se implementar coisas interessantes sobre os tokens.
> 
> O token pode conter informações associadas que poderão ser usadas para confrontar com informações obtidas sobre o cliente em cada requisição.
> 
> Por exemplo
> 
>     - você pode associar um 'user id' (geralmente eu envio, via headers, o id do user que está chamando o end point)
>     - você pode associar uma 'allowed origin' (e negar requisições com esse token se feita de uma origem desconhecida)
> 
> Enfim ... há uma série de coisas que poderão ser implementadas no sentido de validar o acesso. é óbvio que há coisas que podem ser burladas quando feita a requisição (mascarando), porém, pra burlar isso, a pessoa precisa conhecer todo seu esquema de validação.
> 
> 
> 
> 
> -- 
> Eduardo Almeida - Software Engineer
> eduardo at web2solutions.com.br <mailto:eduardo at web2solutions.com.br> - 27 3261-0082 / 27 9839 3755
> 
> WEB2 Solutions - Inovando, sempre! 
> <dhtmlx_certified.png>
> =begin disclaimer
>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150302/95d4dff2/attachment-0001.html>