<p dir="ltr">A autenticação é ortogonal ao resource. Vou tentar elaborar melhor depois, mas o que está rolando é uma confusão.</p>
<div class="gmail_quote">Em 02/03/2015 09:50, "Eduardo Almeida" <<a href="mailto:eduardo@web2solutions.com.br">eduardo@web2solutions.com.br</a>> escreveu:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 3/2/15 9:41 AM, Marcelo Milhomem
wrote:<br>
</div>
<blockquote type="cite">
<div>Enviar o ID do usuário em toda requisição é ruim,
ele acaba sendo redundante e fazendo par com o token.</div>
</blockquote>
Sim e não. Eu apenas quiz citar exemplos.<br>
<blockquote type="cite">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
</blockquote>
<br>
<blockquote type="cite">
<div>Um tópico importante citado por outros é que o seu
método de autenticação tem que ser suportado largamente</div>
</blockquote>
quando sua API é pública.<br>
<blockquote type="cite">
<div> 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.</div>
<div><br>
</div>
<div>Abs,</div>
<br>
<div>
<blockquote type="cite">
<div>On Mar 1, 2015, at 11:46 PM, Eduardo Almeida
<<a href="mailto:eduardo@web2solutions.com.br" target="_blank">eduardo@web2solutions.com.br</a>>
wrote:</div>
<br>
<div>
<div bgcolor="#FFFFFF" text="#000000">
<div>On 3/1/15 11:34 PM, Eduardo
Almeida wrote:<br>
</div>
<blockquote type="cite">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.</blockquote>
Dá para se implementar coisas interessantes sobre os
tokens.<br>
<br>
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.<br>
<br>
Por exemplo<br>
<br>
- você pode associar um 'user id' (geralmente eu
envio, via headers, o id do user que está chamando o end
point)<br>
- você pode associar uma 'allowed origin' (e negar
requisições com esse token se feita de uma origem
desconhecida)<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<div>-- <br>
Eduardo Almeida - Software Engineer<br>
<a href="mailto:eduardo@web2solutions.com.br" target="_blank">eduardo@web2solutions.com.br</a>
- 27 3261-0082 / 27 9839 3755<br>
<br>
<b>WEB2 Solutions</b> - Inovando, sempre! <br>
<span><dhtmlx_certified.png></span></div>
</div>
=begin disclaimer<br>
Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>=begin disclaimer
Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a>
SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a>
L<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank"><http://mail.pm.org/mailman/listinfo/saopaulo-pm></a>
=end disclaimer
</pre>
</blockquote>
<br>
<br>
<div>-- <br>
Eduardo Almeida - Software Engineer<br>
<a href="mailto:eduardo@web2solutions.com.br" target="_blank">eduardo@web2solutions.com.br</a> - 27 3261-0082 / 27 9839 3755<br>
<br>
<b>WEB2 Solutions</b> - Inovando, sempre!
<br>
<img src="cid:part6.00000500.01080906@web2solutions.com.br"></div>
</div>
<br>=begin disclaimer<br>
Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div>