<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Enviar o ID do usuário em toda requisição é ruim, ele acaba sendo redundante e fazendo par com o token.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Abs,</div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 1, 2015, at 11:46 PM, Eduardo Almeida <<a href="mailto:eduardo@web2solutions.com.br" class="">eduardo@web2solutions.com.br</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix">On 3/1/15 11:34 PM, Eduardo Almeida
wrote:<br class="">
</div>
<blockquote cite="mid:54F3CC4F.9080701@web2solutions.com.br" type="cite" class="">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 class="">
<br class="">
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 class="">
<br class="">
Por exemplo<br class="">
<br class="">
- você pode associar um 'user id' (geralmente eu envio, via
headers, o id do user que está chamando o end point)<br class="">
- você pode associar uma 'allowed origin' (e negar requisições
com esse token se feita de uma origem desconhecida)<br class="">
<br class="">
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 class="">
<br class="">
<br class="">
<br class="">
<br class="">
<div class="moz-signature">-- <br class="">
Eduardo Almeida - Software Engineer<br class="">
<a class="moz-txt-link-abbreviated" href="mailto:eduardo@web2solutions.com.br">eduardo@web2solutions.com.br</a> - 27 3261-0082 / 27 9839 3755<br class="">
<br class="">
<b class="">WEB2 Solutions</b> - Inovando, sempre!
<br class="">
<span id="cid:part1.08090807.03010902@web2solutions.com.br"><dhtmlx_certified.png></span></div>
</div>
=begin disclaimer<br class=""> Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" class="">http://sao-paulo.pm.org/</a><br class=""> SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" class="">SaoPaulo-pm@pm.org</a><br class=""> L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" class="">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br class="">=end disclaimer<br class=""></div></blockquote></div><br class=""></body></html>