[SP-pm] Autenticação REST

[Leonardo Ruoso]

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.
Em 02/03/2015 11:12, "Leonardo Ruoso" <leonardo em ruoso.com> escreveu:

> 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/bb923027/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/bb923027/attachment-0001.png>