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
<[email protected] <mailto:[email protected]>>
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
[email protected] - 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: [email protected] <mailto:[email protected]>
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: [email protected]
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer
--
Eduardo Almeida - Software Engineer
[email protected] - 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: [email protected]
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer
