Autenticação de Serviços REST

Debugger Membro desde: 06/07/2011 07:03:19 Mensagens: 66 Offline

AUser wrote: Aí eu te pergunto novamente: como fazemos essa autorização? Esse é um dos pontos que não entendo em REST...

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

GUJ Master Membro desde: 23/10/2008 06:39:07 Mensagens: 1092 Offline

moscoso.dev wrote:

AUser wrote: Aí eu te pergunto novamente: como fazemos essa autorização? Esse é um dos pontos que não entendo em REST...

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

Debugger Membro desde: 06/07/2011 07:03:19 Mensagens: 66 Offline

AUser wrote:

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.

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

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://en.wikipedia.org/wiki/OAuth
http://oauth.net/

GUJ Master Membro desde: 23/10/2008 06:39:07 Mensagens: 1092 Offline

FernandoFranzini wrote: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://en.wikipedia.org/wiki/OAuth
http://oauth.net/

Opa Fernando,

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

[]'s

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

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

Sim...uso SOAP hoje por que:
- 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.....

Debugger Membro desde: 06/07/2011 07:03:19 Mensagens: 66 Offline

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?

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

um cliente mobile, uma aplicação nativa em iOS ou Android, que não suporta uso de cookies e JSESSIONIDS da vida.

Suporta sim...faz tempo......

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

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.

Debugger Membro desde: 06/07/2011 07:03:19 Mensagens: 66 Offline

eldontc wrote: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.

Notícias, artigos e o maior fórum brasileiro sobre Java