[SP-pm] Autenticação REST

[Leonardo Ruoso]

A autenticação é ortogonal ao resource. Vou tentar elaborar melhor depois,
mas o que está rolando é uma confusão.
Em 02/03/2015 09:50, "Eduardo Almeida" <eduardo em web2solutions.com.br>
escreveu:

>  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> 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
> 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> <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!
>
> =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
>
>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150302/c8272c24/attachment-0001.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/c8272c24/attachment-0001.png>