Estou com um impasse atualmente, pois gostaria de saber qual a melhor abordagem para o cenário abaixo:
Estou desenvolvendo um sistema, onde deve funcionar como os serviços do google, onde nos autenticamos no gmail, por exemplo, e consequentemente conseguimos acessar qualquer outro aplicativo do google sem realizar login novamente.
Bom, no meu caso, tenho vários webservices, e estou pensando em criar um webservice somente para autenticação, com metodos de login, logout e validação.
O login retornaria um token de acesso.
Assim, todos os serviços recebem este token, e chamam o webservice de autenticação para validar o token antes de qualquer ação.
Seria esta uma boa pratica para este caso ? Ou a melhor abordagem seria autenticar diretamente em cada um dos webservices ?
Porém na realidade, minha dúvida não se trata do token em sí, mas sim da melhor arquitetura que devo escolher em meu caso.
Pois estou indeciso entre sempre criar uma autenticação em cada serviço, assim sempre que receberem um request eu valido o token.
Ou crio um webservice central somente para autenticação, ao qual gera um token, assim sempre que um usuario requisitar algo do serviço X, este serviço remotamente chama o serviço de autenticação e verifica se o token é valido ou nao antes de continuar com o processo.
[quote]Porém na realidade, minha dúvida não se trata do token em sí, mas sim da melhor arquitetura que devo escolher em meu caso.
Pois estou indeciso entre sempre criar uma autenticação em cada serviço, assim sempre que receberem um request eu valido o token.
Ou crio um webservice central somente para autenticação, ao qual gera um token, assim sempre que um usuario requisitar algo do serviço X, este serviço remotamente chama o serviço de autenticação e verifica se o token é valido ou nao antes de continuar com o processo.[/quote]
Você já está autenticando no google, então você já possui o token e já enviou ao usuário, o que você precisa é só autenticar esse token em cada request. Não é necessário logar ele toda vez que fizer um request ao seu serviço. Creio que o método do google seja Oauth2, então o mesmo deveria se autenticar utilizando SSL.
[quote=clunsde][quote]Porém na realidade, minha dúvida não se trata do token em sí, mas sim da melhor arquitetura que devo escolher em meu caso.
Pois estou indeciso entre sempre criar uma autenticação em cada serviço, assim sempre que receberem um request eu valido o token.
Ou crio um webservice central somente para autenticação, ao qual gera um token, assim sempre que um usuario requisitar algo do serviço X, este serviço remotamente chama o serviço de autenticação e verifica se o token é valido ou nao antes de continuar com o processo.[/quote]
Você já está autenticando no google, então você já possui o token e já enviou ao usuário, o que você precisa é só autenticar esse token em cada request. Não é necessário logar ele toda vez que fizer um request ao seu serviço. Creio que o método do google seja Oauth2, então o mesmo deveria se autenticar utilizando SSL.
Espero ter ajudado, abraços![/quote]
Clunsde, obrigado pela dica,
Porém não estou utilizando nada do google, nem me conecto a ele, eu só dei um exemplo de como funcionam os serviços deles.
O meu prblema é que eu estou desenvolvendo diversos webservices proprios que compõem um sistema ao todo…e queria saber qual a melhor abordagem para a autenticação dos usuários:
1 - Cada serviço realizar a autenticação em sí mesmo
2 - Criar um webservice central de autenticação que todos os serviços o chamam para verificar se o usuario é valido.
Os dois modos funcionam, porém gostaria de saber qual a “boa pratica” aqui.
[quote=guilherme.dio]Porém não estou utilizando nada do google, nem me conecto a ele, eu só dei um exemplo de como funcionam os serviços deles.
O meu prblema é que eu estou desenvolvendo diversos webservices proprios que compõem um sistema ao todo…e queria saber qual a melhor abordagem para a autenticação dos usuários:
1 - Cada serviço realizar a autenticação em sí mesmo
2 - Criar um webservice central de autenticação que todos os serviços o chamam para verificar se o usuario é valido.
Os dois modos funcionam, porém gostaria de saber qual a “boa pratica” aqui.[/quote]Parceiro, não creio que exista uma boa prática mas sim requisito.
É requisito fazer o login a cada projeto ou manter um login único? Quando é login único, você vai ter que centralizar uma lógica onde todos os projetos acessarão. Quando o login é separado vc precisará fazer a lógica em cada projeto (até mesmo repetir código), mas a complexidade vai diminuir.
No seu caso eu vejo que isso é mais problema de requisito do que boa prática.
[quote=guilherme.dio]
Clunsde, obrigado pela dica,
Porém não estou utilizando nada do google, nem me conecto a ele, eu só dei um exemplo de como funcionam os serviços deles.
O meu prblema é que eu estou desenvolvendo diversos webservices proprios que compõem um sistema ao todo…e queria saber qual a melhor abordagem para a autenticação dos usuários:
1 - Cada serviço realizar a autenticação em sí mesmo
2 - Criar um webservice central de autenticação que todos os serviços o chamam para verificar se o usuario é valido.
Os dois modos funcionam, porém gostaria de saber qual a “boa pratica” aqui.[/quote]
Quem irá se comunicar com os serviços? Outros sistemas? Ou o usuário final? Se for outro sistema, o mesmo pode ser implementado em várias formas, você pode desbloquear acesso apenas por IP, você pode utilizar certificados digitais, você pode utilizar tokens, etc. Se for para usuário final, você pode utilizar da mesma forma que o google (OAuth 2). O spring security já possui as implementações necessárias para o OAuth 2.
[quote=Hebert Coelho][quote=guilherme.dio]Porém não estou utilizando nada do google, nem me conecto a ele, eu só dei um exemplo de como funcionam os serviços deles.
O meu prblema é que eu estou desenvolvendo diversos webservices proprios que compõem um sistema ao todo…e queria saber qual a melhor abordagem para a autenticação dos usuários:
1 - Cada serviço realizar a autenticação em sí mesmo
2 - Criar um webservice central de autenticação que todos os serviços o chamam para verificar se o usuario é valido.
Os dois modos funcionam, porém gostaria de saber qual a “boa pratica” aqui.[/quote]Parceiro, não creio que exista uma boa prática mas sim requisito.
É requisito fazer o login a cada projeto ou manter um login único? Quando é login único, você vai ter que centralizar uma lógica onde todos os projetos acessarão. Quando o login é separado vc precisará fazer a lógica em cada projeto (até mesmo repetir código), mas a complexidade vai diminuir.
No seu caso eu vejo que isso é mais problema de requisito do que boa prática.[/quote]
Ola Hebert, obrigado pelo conselho.
No meu caso, a especificação é justamente login unico para todos os serviços, bem parecido com o esquema do google(onde você acessa todos os services deles com seu email).
Portanto o melhor seria criar um webservice central de autenticação, e todos os outros serviços ao receberem o request, fazem uma chamada primeiro a este serviço de autenticação e verifica se o usuario é valido e se esta na sessão.
Se puderem me dar outras sugestões da arquitetura, fico feliz, pois no momento estou definindo a melhor abordagem mesmo.
Muito bom, já tinha ouvido falar porém nunca usei. Vou ler a documentação.
Entretanto tenho uma outra muralha que pode me atrapalhar, já que o login/senha dos usuarios que utilizaram o sistema não fica em tabelas como em um sistema comum, mas as credenciais são diretas do Oracle.
Ou seja, o login do usuario é um login do Oracle, pois foi todo estruturado utilizando regras de roles entre outras politicas de acesso do Oracle, assim um usuario realizando um mesmo select que outro não recebe as mesmas informações já que os dois possuem acessos diferentes.
Então nesse caso, para autenticar e gerar o token será algo meio “estranho” se comparado a um sistema comum onde você acessa a base com um login unico da aplicação e vê se o usuario existe na tabela de usuarios.
No meu caso vou ter que tentar conectar, se der o usuario é valido, senão não. A partir disso vou ter que gerar o token e gravar um sessão para este usuario no banco de serviços.
Porém parando para pensar, não vejo uma vantagem do uso do token aqui, por conta deste acesso do Oracle…será que é mesmo vantagem ?
[quote=guilherme.dio]Entretanto tenho uma outra muralha que pode me atrapalhar, já que o login/senha dos usuarios que utilizaram o sistema não fica em tabelas como em um sistema comum, mas as credenciais são diretas do Oracle.
Ou seja, o login do usuario é um login do Oracle, pois foi todo estruturado utilizando regras de roles entre outras politicas de acesso do Oracle, assim um usuario realizando um mesmo select que outro não recebe as mesmas informações já que os dois possuem acessos diferentes.
Então nesse caso, para autenticar e gerar o token será algo meio “estranho” se comparado a um sistema comum onde você acessa a base com um login unico da aplicação e vê se o usuario existe na tabela de usuarios.
No meu caso vou ter que tentar conectar, se der o usuario é valido, senão não. A partir disso vou ter que gerar o token e gravar um sessão para este usuario no banco de serviços.
Porém parando para pensar, não vejo uma vantagem do uso do token aqui, por conta deste acesso do Oracle…será que é mesmo vantagem ?[/quote]estranho? Qual a diferença de fazer login em app x ou y?
O processo de login sempre é saber se você tem uma credencial válida e o perfil necessário para acessar determinado recurso…
Existem sistemas que tem apenas um servidor e um front end que se comunicam por token e nada mais.
Token no banco? O que você entende por token? Pq esse token ñ é uma informação criptografada que só seu projeto terá a chave? Assim você consegue validar as informações… Vc não vai ter um serviço único de login? basta que esse cara também tenha o papel de proxy, ele quem chamará seu servidor e não o usuário. Ou seja, se o usuário chamar seuProjeto/aaa você validará a chamada, se foi tudo com sucesso, aí você pode fazer o request (ao servidor escolhido) e depois retornar a resposta…