Primeiros passos com Spring Social: visão geral do fluxo WebappOAuth 2.0
Em meus últimos artigos, tenho falado sobre como acessar provedores de Software as Service (SaaS), como o Facebook e o Twitter, usando Spring Social. Estou me concentrando no OAuth 2.0 e sugeri também que antes de solicitar um token de acesso o seu aplicativo precisa de um código de autorização, o que combina com o seu app secreto. Este artigo se aprofunda mais um pouco e explica o que está acontecendo – pelo menos no caso do OAuth 2.0.
Em meus últimos artigos, tenho falado sobre como acessar provedores de Software as Service (SaaS), como o Facebook e o Twitter, usando Spring Social. Alguns de vocês podem ter notado que meu código de exemplo pode ter sido um pouco mais simples, enquanto eu tenho tentado descrever o que está acontecendo no background e o que o Spring Social está fazendo por você.
Até agora, eu tenho tido a visão de um pássaro no OAuth, definindo-o como a necessidade de seu aplicativo para se apossar de um token de acesso, de modo que ele possa acessar dados privados de seus usuários a partir de um provedor de SaaS, sem a necessidade dos seus usuários para fornecer suas credenciais ao seu app. Estou me concentrando no OAuth 2.0 e sugeri também que antes de solicitar um token de acesso o seu aplicativo precisa de uma coisa chamada código de autorização, o que combina com o seu app secreto.
Este artigo se aprofunda mais um pouco e explica o que está acontecendo – pelo menos no caso do OAuth 2.0.
Uma coisa para lembrar sobre OAuth 2.0 é que existem seis fluxos diferentes que abrangem diferentes cenários de cliente, tais como o fluxo de User-Agent e o Fluxo de dispositivos. Essa descrição abrange o fluxo de Web Server para clientes OAuth que fazem parte de um aplicativo de servidor web.
As etapas resumidas do OAuth
Em resumo, no fluxo de Web Server, as etapas de alto nível são as seguintes:
- O usuário se conecta a seu provedor de SaaS
- Um código de autorização é enviado para seu aplicativo.
- O aplicativo usa o código de autorização para recuperar um token de acesso
- O token de acesso é usado para recuperar dados privados do usuário
Para alguns, uma visão de alto nível será suficiente, mas, se você for como eu, então você vai querer compreender alguns dos detalhes práticos do que está acontecendo.
Obter uma token de autorização OAuth 2.0 muitas vezes se refere à “Dança do OAuth”, e nessa dança há três bailarinos ou atores:
Atores OAuth
|
Ator |
Descrição |
| Usuário | O navegador do usuário controlado como por um usuário humano |
| TheApp | O webapp que deseja acessar os dados do usuário SaaS |
| SaaS App | O provedor de Software as a Service, como o Facebook |
A Dança do OAuth
A tabela abaixo descreve a dança do OAuth 2.0 em detalhe…
|
Ator |
Descrição |
Dados |
| Usuário | Navega para TheApp no navegador. TheApp no carregamento de uma página precisa solicitar os dados SaaS | |
| TheApp | TheApp não possui token de acesso para este usuário neste provedor de SaaS e não pode retornar os dados de SaaS. Ele retorna informações suficientes para que o/a usuário/usuário solicitar um. | authorize_url (a URL do serviço SaaS OAuth) redirect_uri client_id (app key) response_type: code |
| Usuário | Os contatos do usuário do provedor de SaaS pedindo um token de acesso. | Faz que um GET para o authorize_url do SaaS passando os seguintes parâmetros: client_id: (appkey) redirect_url: response_type: code |
| SaaS | Responde com a página de login do usuário no webapp SaaS. | |
| Usuário | Digita seu nome de usuário e senha no site SaaS e pressiona ok. | Envia de volta detalhes de login SaaS, como o nome de usuário e a senha. |
| SaaS | O provedor SaaS pede ao usuário para confirmar que TheApp pode acessar seus dados. Ele geralmente faz isso por meio da apresentação de uma pequena tela que pede algo como: “Você deseja que TheApp acesse os seus dados de SaaS?” | Este é o REST, então os seguintes são carregados em campos ocultos: client_id: (appkey) redirect_url: response_type: code |
| Usuário | Confirma o acima citado para o SaaS. | client_id: (app key) redirect_url: response_type: code authorize=1 (or YES) |
| SaaS | O provedor SaaS não cria imediatamente o token de acesso. Em vez disso, cria um código de autorização e o armazena para mais tarde, antes de passá-lo de volta para o usuário. O token de acesso pode ser solicitado e gerado usando este código. O provedor de SaaS transmite o código para o usuário, como parte de um redirecionamento HTTP (códigos de status 3xx). | O redirecionamento é redirect_url do TheApp e contém:code: (código de autorização)expires_in: (tempo de validade) |
| Usuário | Faz um redirecionamento utilizando a URL da última etapa de volta para TheApp com uma requisição GET. | código: (código de autorização)expires_in: (tempo de validade) |
| TheApp | TheApp então chama o provedor de SaaS usando um POST para recuperar o token de acesso | client_id (o ID do App/Key)client_secretcode (o código secreto do app)redirect_urlgrant_type: autorização de código |
| SaaS | O provedor de SaaS reconhece o código de autorização e cria o token de acesso. Ele também revoga o código de autorização. |
Retorna o token de acesso para TheApp access_token (o estimado token de acesso) expires_in (tempo de expiração) refresh_token |
| TheApp | TheApp informa ao usuário que o processo OAuth funcionou. | |
| TheApp | TheApp já pode acessar os dados SaaS do usuário, utilizando uma solicitação GET. | Passa o token de acesso como header HTTP de (ou parêmetro de pedido) Por exemplo: https://graph.facebook.com/me/friends?access_token=AAAAAAITEghMWiBBlEC5OG … etceAVbjNnWjIlE … |
| Usuário | O usuário agora vê seus dados SaaS conforme exibido pelo TheApp em seu navegador. |
Na tabela acima, eu incluí muitos dos parâmetros de dados que são realizadas por meio de solicitação para solicitação, mesmo que não sejam sempre necessários nesse ponto na sequência. Uma coisa para se lembrar aqui é que por uma razão muito prática um provedor de SaaS é um serviço REST e, portanto, não mantém o estado entre as solicitações de clientes.
Um último ponto para se observar aqui é que tudo isso acontece usando SSL para garantir que as chaves, os segredos, os códigos etc. estão escondidos de olhares indiscretos.
Uma boa maneira de ver tudo isso em ação é criar uma conta no Hootsuite e usá-la para acessar os dados do seu Twitter, Facebook, LinkedIn dentre outros: todas as telas pop-up nos lugares certos: provavelmente uma implementação clássica.
***
Texto original disponível em http://www.captaindebug.com/2012/07/oauth-20-webapp-flow-overview.html
Trabalha na empresa Bet365 desde 2012. É um programador e desenvolvedor Java com certificado em Sun, com considerável experiência em todos os aspectos do ciclo de desenvolvimento em ambientes financeiros. Seus recentes projetos incluem o uso de Java, Spring e Oracle.
