[SP-pm] Autenticação REST

[Eduardo Almeida]

On 3/2/15 9:41 AM, Marcelo Milhomem wrote:
> Enviar o ID do usuário em toda requisição é ruim, ele acaba sendo 
> redundante e fazendo par com o token.
Sim e não. Eu apenas quiz citar exemplos.
>
> 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
quando sua API é pública.
> 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 em web2solutions.com.br <mailto:eduardo em 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 em 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 em pm.org <mailto:SaoPaulo-pm em pm.org>
>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>
>
>
> =begin disclaimer
>     Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>   SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>   L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer


-- 
Eduardo Almeida - Software Engineer
eduardo em web2solutions.com.br - 27 3261-0082 / 27 9839 3755

*WEB2 Solutions* - Inovando, sempre!
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150302/894584d1/attachment.html>
-------------- Pr?xima Parte ----------
Um anexo n?o-texto foi limpo...
Nome: dhtmlx_certified.png
Tipo: image/png
Tamanho: 11630 bytes
Descri??o: n?o dispon?vel
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150302/894584d1/attachment.png>