Enviar o ID do usuário em toda requisição é ruim, ele acaba sendo redundante e fazendo par com o token.
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 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]> > 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] <mailto:[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] > 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
