<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>