Autenticação de Serviços REST

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.

Abraços, valeu.

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.

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 .

links que já pesquisei:

http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.html
http://architects.dzone.com/news/rest-and-http-digest
http://thewalter.net/stef/software/httpauth/
http://hueniverse.com/oauth/

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.

Qualquer ajuda será bem-vinda! Saúde galera!

Galera,

Andei pesquisando sobre essa questao, e achei esse artigo muito interessante:

http://www.artima.com/weblogs/viewpost.jsp?thread=155252

[]'s

O google por exemplo usa uma assinatura, que deve ser passada na requisição.

http://code.google.com/intl/pt-BR/apis/maps/documentation/webservices/index.html#URLSigning

Exemplo:
http://code.google.com/intl/pt-BR/apis/maps/documentation/places/

E um token SAML não seria legal?

Mas o token não ia resolver a questão de authorization… É isso que não entendo em REST, como funciona a questão de Authorization?

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?

foi mal, é que eu só lí o título do tópico e achava que era só autenticação

a autorização poderia ser feita em código mesmo, não valeria a pena?

ou no caso do Java, colocar uma anotação nos métodos REST com Spring para dar um security exception caso o cara não tenha autorização

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

1. Usar HTTP BASIC com HTTPS
2. 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+

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.

É possível e bastante comum manter estado no REST. Só não usa cookies.

Basicamente no servidor você retorna 401 (Authorization Required) na ausência do request header Authorization: Basic <Base64 do usuário:password>.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8

Basicamente no servidor você retorna 401 (Authorization Required) na ausência do request header Authorization: Basic <Base64 do usuário:password>.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.8

Opa!

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?

[]'s!

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.

Abracos

AUser:

Opa!

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!

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.

FernandoFranzini:

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.

http://oauth.net/

Opa Fernando,

Mas você já se precisou decidir entre SOAP ou REST? Teve alguma característica que te influenciou?

[]'s

AUser:

Opa Fernando,
Mas você já se precisou decidir entre SOAP ou REST? Teve alguma característica que te influenciou?
[]'s

• Mais usado hoje
• Mais ferramentas
  Com a criação do WSDL REST, esta praticamente se tornando um “SOAP”, usando protocolo HTTP.
  Ou seja, na verdade mesmo, eliminou apenas o overred…
  Mas nos temos q estar preparado para ambos…

Se seu sistema for web, SOAP não é uma opção.

Pois é galera, vi ser mencionado o oAuth como opção. Acontece que as implementações de oAuth que vi sempre resolvem o problema de autenticação onde existem 3 envolvidos.
1 - Um provedor de informação, por exemplo, um site que armazena fotos.
2 - Um consumidor de serviço, por exemplo, um site que deseja buscar fotos no provedor de informação, por exemplo, buscar fotos.
3 - O usuário que é dono da informação no site provedor, por exemplo, um usuário que tem as fotos armazenadas no site que armazena fotos.

Daí ocorre a chamada “Dance” no jargão oAuth, onde o usuário autoriza o consumidor de serviços a utilizar os dados no provedor em seu nome.

Existem outros cenários, por exemplo, quando você aceita que um site utilize sua conta do Google ou Facebook para se autenticar neste site, geralmente é feito com oAuth também. No oAuth 2, existe um outro modelo chamado de 2-legged que, pelo que entendi, serviria para autenticação simples entre usuário e site de serviços diretamente.

O fato é, quando temos um implementação REST, estamos dispostos a entregar recursos / estados armazenados em um servidor para qualquer cliente que chame por uma URL / verbo HTTP. Não podemos partir da premissa que temos um browser do outro lado, pode ser por exemplo, um cliente mobile, uma aplicação nativa em iOS ou Android, que não suporta uso de cookies e JSESSIONIDS da vida.

A questão continua aberta, como tratar a autenticação e manutenção desta autenticação entre requests, em um modelo REST de desenvolvimento?

Suporta sim…faz tempo…

Use autenticação por request!!! Minimize o impacto usando cache de autenticações para não gastar recursos…entre as repetidas autenticações.

Putz, implementa mesmo, via [[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookieAcceptPolicy:NSHTTPCookieAcceptPolicyAlways];, no caso do iOS.
Analisando melhor o meu próprio post, acho difícil realmente um dispositivo ser capaz de invocar URLs e não implementar a guarda de cookies. Vivendo e aprendendo.
Valeu pela informação Fernando Franzini.

eldontc:

Putz, implementa mesmo, via [[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookieAcceptPolicy:NSHTTPCookieAcceptPolicyAlways];, no caso do iOS.
Analisando melhor o meu próprio post, acho difícil realmente um dispositivo ser capaz de invocar URLs e não implementar a guarda de cookies. Vivendo e aprendendo.
Valeu pela informação Fernando Franzini.

Twitter direciona para o browser para completar a autorização via OAuth.

Para uma autenticacao segura REST, você pode usar o mesmo procedimento que a Amazon utiliza:

http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

Os anos se passaram… Alguém conseguiu implementar algo legal para segurança REST ?

Usar o OAuth 2 com spring security 4 é muito complexo. Não vejo um tutorial simples com alguma solução funcional.

Me parece um canhão para matar uma formiga, ninguém tem um meio termo ?

abcs

Para informação sobre autenticação: