we are developers
Back-End
Tem 12 artigos publicados com 14400 visualizações desde 2011
É engenheiro de software desde 1996. Desde 2008, trabalha no departamento de R&D da Zend Technologies, uma empresa de PHP que fica em Cupertino, Califórnia. Programa em Basic, C/C++, Assembly 80×86, dBase III, Delphi, Visual Basic, ASP/.NET, Perl, PHP, Python, Java e JavaScript. É um entusiasta do open source e colaborador de projetos em Zend Framework e Apigility, além de arquiteto certificado do Zend Framework e do PHP.
Na primeira parte, vimos considerações de segurança do OAuth2, configuração do OAuth2no Apigility e aplicativos Web-servidor. Agora, falarei sobre aplicativos baseados no navegador, aplicativos móveis, nome de usuário e senha de acesso e acesso ao aplicativo.
***
Esse cenário é muito comum quando você tem um cliente JavaScript (por exemplo, um aplicativo de Página Única) que solicita acesso à API de um servidor de terceiros.
Em um aplicativo baseado em navegador, você não pode armazenar o client_secret de forma segura, o que significa que você não pode usar o fluxo anterior. Precisamos usar um implicit grant. Isso é semelhante ao código de autorização, mas em vez de um código de autorização ser devolvido a partir do pedido de autorização, um token é devolvido.
No diagrama a seguir, informamos os dois passos necessários para a autenticação em cenários de aplicativos baseados em navegador:
O aplicativo baseado no navegador requisita a página de autorização ao serviço de terceiros (Passo 1). Essa página contém os botões Allow/Deny para autorizar o acesso da API à aplicação. Se o usuário clicar no botão Allow, o servidor de terceiros envia o token de acesso utilizando o identificador de fragmento URI (#access_token na Etapa 2). A utilização do identificador de fragmento para o access_token é importante aqui, do ponto de vista da segurança, uma vez que o sinal não é transmitido para o servidor, o escopo do token é apenas no lado do cliente (do browser).
O cenário de aplicativos baseados em navegador é suportado pelo Apigility usando o tipo implict grant. Esse tipo de concessão é desabilitado por padrão e você precisa ativá-lo manualmente, mudando a configuração de allow_implicit para true no arquivo /config/autoload/local.php:
Depois dessa mudança, podemos requisitar um token de acesso usando a aplicação baseada no navegador com 2 passos:
1) Requisite o token de autorização
Precisamos requisitar a mesma URL do passo 1 do cenário de aplicativos Web-servidor (mostrado no artigo anterior):
http:///oauth/authorize?response_type=token
&client_id=testclient&redirect_uri=/oauth/receive
Veremos a mesma página da aplicação Web-servidor perguntando pela autorização da aprovação.
2) Aprove a autorização de acesso
Se aprovarmos o acesso clicando em Yes, o Apigility enviará o token de acesso para a redirect_uri usando o identificador de fragmento URI (#access_token).
Em nosso exemplo, redirecionamos o token de acesso para o /oauth/receive, exibido abaixo:
Se você clicar no “Click here to read”, verá o token de accesso aparecer na página. Essa ação é realizada por um script JavaScript simples que faz o parser da URL para extrair o valor do access_token. Um exemplo desse código JavaScript:
Esse cenário OAuth2 é semelhante ao anterior para aplicativos baseados em navegador. A única diferença é o redirect_uri, que no mundo móvel pode ser um esquema URI personalizado. Isso permitirá que os aplicativos móveis nativos possam interagir com um aplicativo web de navegador, abrindo uma URL a partir de um aplicativo nativo e voltar para o app com uma URI customizada.
Por exemplo, aplicativos para iPhone podem registrar um protocolo URI personalizado, como “facebook://”. No Android, os aplicativos podem registrar padrões de correspondência de URLs que irão lançar o app nativo se uma URL correspondente ao padrão é visitada.
Abaixo é exibido o esquema para a autenticação OAuth2 com aplicativos móveis:
Como você pode ver no diagrama, é um mecanismo de autenticação de dois passos como para os aplicativos baseados em navegador.
Esse caso de uso pode ser usado para autenticar uma API com acessos concedidos com base no usuário (submetendo o password). O cenário típico inclui uma página de login com nome de usuário e senha usados para autenticar uma API. Acesso com senha só é apropriado para clientes confiáveis. Se você construir seu próprio site como um cliente de sua API, então essa é uma ótima maneira de lidar com login.
O mecanismo de autenticação é muito simples e tem apenas um passo (veja a figura abaixo).
A aplicação cliente envia um POST para o servidor OAuth2 com os valores de usuário e senha. O servidor OAuth2 dá o token de acesso como resposta em formato JSON.
Esse caso de uso pode ser usado para autenticar o acesso ao aplicativo, mais provável em cenários de máquina para máquina. O tipo de concessão OAuth2 para esse caso de uso é o client_credential. O uso é semelhante ao nome de usuário e senha de acesso relatado acima – o aplicativo envia uma solicitação POST ao servidor OAuth2 passando o client_id, o client_secret, que age como a senha do usuário. O servidor responde com o token se as credenciais do cliente forem válidas.
O protocolo OAuth2 dá a possibilidade de atualizar o token de acesso gerando um novo, com um novo tempo de vida. Essa ação pode ser realizada utilizando o refresh_token que o servidor OAuth2 dá como resposta durante o passo da autenticação.
No Apigility, você pode atualizar o token de acesso com um POST para o terminal do servidor OAuth2. No nosso exemplo de banco de dados OAuth2, podemos realizar um token de atualização usando o seguinte comando:
http -f POST http:///oauth grant_type=refresh_token
refresh_token= client_id=testclient
client_secret=testpass
A resposta será algo semelhante a:
Em agosto de 2013, o IETF publicou a RFC 7009 sobre a revogação de token OAuth2. A versão 0.8 atual do Apigility não suporta a revogação do token, mas vamos suportar esse recurso em breve. De qualquer forma, ainda é possível revogar um token de acesso específico, utilizando o banco de dados PDO. Todos os sinais são armazenados na tabela de oauth_access_tokens, se você quer revogar um token poderá excluí-lo da tabela, com uma consulta SQL assim:
DELETE FROM oauth_access_tokens WHERE access_token = “”;
No Apigility, começamos a oferecer suporte para a autenticação OAuth2 a partir da versão 0.8. Nós ainda estamos trabalhando em algumas das características desse protocolo, como a revogação do token. Estamos coletando feedbacks da comunidade e, se você quer compartilhar seus comentários que são mais do que bem-vindos, junte-se às nossas listas de email apigility-user ou apigility-dev. Mais informações estão disponíveis no site oficial do projeto, apigility.org.
***
Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em http://www.zimuel.it/oauth2-apigility/
De 0 a 10, o quanto você recomendaria este artigo para um amigo?
É engenheiro de software desde 1996. Desde 2008, trabalha no departamento de R&D da Zend Technologies, uma empresa de PHP que fica em Cupertino, Califórnia. Programa em Basic, C/C++, Assembly 80×86, dBase III, Delphi, Visual Basic, ASP/.NET, Perl, PHP, Python, Java e JavaScript. É um entusiasta do open source e colaborador de projetos em Zend Framework e Apigility, além de arquiteto certificado do Zend Framework e do PHP.
Fique em dia com as novidades do iMasters! Assine nossa newsletter e receba conteúdos especiais curados por nossa equipe
