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.

***

Aplicativos baseados em navegador

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:

return array(
    'zf-oauth2' => array(
        // ...
        'allow_implicit' => true,
        // ...
    ),
);

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:

// function to parse fragment parameters
var parseQueryString = function( queryString ) {
    var params = {}, queries, temp, i, l;
 
    // Split into key/value pairs
    queries = queryString.split("&");
 
    // Convert the array of strings into an object
    for ( i = 0, l = queries.length; i < l; i++ ) {
        temp = queries[i].split('=');
        params[temp[0]] = temp[1];
    }
    return params;
};
 
// get token params from URL fragment
var tokenParams = parseQueryString(window.location.hash.substr(1));

Aplicativos móveis

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.

Nome de usuário e senha de acesso

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.

Acesso à aplicação

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.

Atualize o token OAuth2

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:

{
    "access_token": "470d9f3c6b0371ff2a88d0c554cbee9cad495e8d",
    "expires_in": 3600,
    "scope": null,
    "token_type": "Bearer"
}

Revogar o token OAuth2

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 = “”;

Conclusão

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/