Então pessoal, comecei a criar alguns serviços REST para evitar futurod problemas de acomplamentos entre outras coisas.
Diante desse cenário de ja possuo algumas aplicações clientes para consumirem esses serviços,
porém os serviços estão totalmente abertos, ou seja, senha nenhuma autenticação e autorização.
Andei pensando em algumas API’s como a do twitter, a google, entres outras, também li um pouco sobre OAuth,
mas ainda sim gostaria de saber opinião de vocês em relação a fazer e como fazer autotização e autenticação de API’s, e quem já passou por isso qual a solução utilizada.
Não tem muito a ver com REST, a não ser que vc passe usar cookies, violando assim a restrição de stateless. No mais basta procurar por autenticação via HTTP.
É isso ai… procurar sobre autenticação HTTP foi o que fiz:
Estou querendo é saber opinião de quem já fez, já estudou, tem sugestão, para poder discutir um pouco sobre,
REST foi so o modelo de serviços que eu implementei como disse no início.
[quote=diguix]É isso ai… procurar sobre autenticação HTTP foi o que fiz:
Estou querendo é saber opinião de quem já fez, já estudou, tem sugestão, para poder discutir um pouco sobre,
REST foi so o modelo de serviços que eu implementei como disse no início.
Abraços, valeu.
[/quote]
Ainda não precisei implementar isso, mas vou precisar em breve.
O que posso dizer é que OAuth só é necessário se vc precisa fazer com que outros sistemas acessem dados dos seus usuários, sem fazer com que seus usuários informem login e senha para o concorrente.
Após um ano, estou com a mesma dúvida do @mochuara. Também dei uma olhada no oAuth, mas me pareceu que o forte dele é autenticação e autorização entre sites, em favor de um usuário. Também li que uma versão 2.0 do oAuth está a caminho e será totalmente diferente da anterior. A dúvida continua, qual a melhor forma de implementar autenticação e autorização no consumo de serviços Rest. Estou usando Spring 3.0.5. Também li sobre Spring Security, mas não fiquei muito satisfeito com ele. Me pareceu bastante complexo e parece não ter nada específico para proteção de serviços implementados com Rest. Devido a natureza stateless do Rest, fica a dúvida, como proteger serviços Rest? As implementações de segurança sob HTTP (Basic e Digest) seriam a solução? Temos os problema do http://en.wikipedia.org/wiki/Man-in-the-middle_attack .
Enfim, quem está desenvolvendo aplicações que oferecem acesso a serviços via Rest, como vocês estão tratando a questão de autenticação e autorização para usuários finais da aplicação. Não estou falando de uso de Rest por outras aplicações, onde o sofisticado oAuth resolve a questão, mas sim dos usuários finais da aplicação.
Uma ideia para resolver a authorization é enviar a identifcação do user “dentro” do token, via https, é claro.
Com isso, um Filter poderia verificar se aquele usuário pertence a uma ROLE que permite a execução do serviço REST.
No cenário acima, o usuário se autenticaria em uma tela de login, por exemplo, informando seu principal (username) e credencials (password). Se a autenticação é bem sucedida, um token de liberação (alguns chamam de ticket) é enviado ao cliente e neste token existem informações de tempo de validade, como se fosse um controle de sessão, ou seja, por quanto tempo a autenticação que o usuário fez vale até o próximo request. Nos próximos requests a coisa se repete, ou seja, um token é enviado novamente ao cliente “renovando” o tempo de validação da autenticação. Lembrando que todos os requests são intercepatados pelo Filter e a verificação do user que está no token é feita em relação as roles do usuário. A vantagem é que a caracterísitca stateless do REST é mantida, sem criação de http session.
A ideia acima resolveria autenticação e autoriazação. o que acham?
Pois é, mas pelo que entendo, em RESTful não há controle de sessão, tudo ia ser feito por cookies no cliente. Aí eu te pergunto novamente: como fazemos essa autorização? Esse é um dos pontos que não entendo em REST…
Olha só…toda interação entre um cliente e um servidor web é “stateless”. Tudo é feito através de um “request” e um “response”, não existe o conceito de manter estado. Daí surgiu o “cookie” que serve para armazenar informações em um arquivo, afim de evitar que se pergunte a cada requisição a mesma informação.
Onde eu quero chegar com isso? Independente do seu design ser RestFul ou não, o protocolo HTTP funciona assim. Ou você armazena isso em algum lugar ou não armazena. Este conceito de que não existe controle de estado no Rest, é conceitual, acredito que quando foi idealizado, não se levou em consideração a necessidade de autenticação e autorização.
Seguindo a filosofia do REST de não usar sessão, vc tem 2 formas
Usar HTTP BASIC com HTTPS
Enviar credenciais dentro do header do HTTP, fazendo autenticação a cada chamada.
Furando a filosofia do REST
1)usando session mesmo da mesma forma que os aplicativos web - na primeira requisição autentica e nas próximas envia o cookies com sessionid.
Não existe problemas nenhum em fazer isso pelo justo fato das limitações do protocolo HTTP.
Podermos esperar uma nova especificação do HTTP logo logo da mesma forma do HTML 5…demoro mas veio!
T+
[quote=Giulliano]
Olha só…toda interação entre um cliente e um servidor web é “stateless”. Tudo é feito através de um “request” e um “response”, não existe o conceito de manter estado. Daí surgiu o “cookie” que serve para armazenar informações em um arquivo, afim de evitar que se pergunte a cada requisição a mesma informação.
Onde eu quero chegar com isso? Independente do seu design ser RestFul ou não, o protocolo HTTP funciona assim. Ou você armazena isso em algum lugar ou não armazena. Este conceito de que não existe controle de estado no Rest, é conceitual, acredito que quando foi idealizado, não se levou em consideração a necessidade de autenticação e autorização.[/quote]
É possível e bastante comum manter estado no REST. Só não usa cookies.
Rapaz, que bom que encontrei alguém que pode me ajudar nas minhas dúvidas de REST, hehe.
Bom, eu nunca entendi cara, se eu armazeno o state no cliente, por meio de cookies, a segurança não fica vulnerável? Seria só alterar o cookie, correto? E caso a política de Authorization mudasse, como ia dar expire no cookie? Resetando o server?
Bom, eu entendo que deve ter alguam meleca no meio das minhas dúvidas, mas é que ainda não consegui compreender mesmo. Você conehce algum exemplo bom na web sobre isso? Em que tipo de aplicações não seria legal usar REST?
se a aplicação é interna, simples regras de firewall deveriam resolver o problema. Se eh externa, um SSL + uma politica de token, ja descrita e nao statefull tambem resolvem.
Rapaz, que bom que encontrei alguém que pode me ajudar nas minhas dúvidas de REST, hehe.
Bom, eu nunca entendi cara, se eu armazeno o state no cliente, por meio de cookies, a segurança não fica vulnerável? Seria só alterar o cookie, correto? E caso a política de Authorization mudasse, como ia dar expire no cookie? Resetando o server?
[]'s! [/quote]
Uma solução restful não usa cookies. Veja meu post anterior.
Eu não uso rest ainda…tudo aqui esta maravilhosamente rodando SOAP!!
Eu vi no ultimo artigo da revista Java Magazine edição 83 o camarada la chamado de João Savio C. Longo sugere o uso de OAuth para autenticação e autorização em WS Rest.
