<p dir="ltr">A autenticação em si não é Rest, nem deveria ser, um diretório seria rest, um sistema de autenticação não. Assim como elementos de autenticação não devem ser incluídos como identificador do de source (como parte só path ou da quer string do do body), da mesma forma como versão de API ou tipo de mídia também não.</p>
<div class="gmail_quote">Em 02/03/2015 11:12, "Leonardo Ruoso" <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>> escreveu:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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" 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>
<br></blockquote></div>
</blockquote></div>