Authorization code grant

Conforme visto na Subseção 2.4.4, o authorization code é um authorization code grant typeque é utilizado para obter o access tokens, sendo otimizado para clients do tipo confidential. Como é baseado num fluxo de redirecionamento, o client deve ser capaz de interagir com o user-agent do resource owner, bem como ser capaz de receber requisições do authorization server.

Figura 2.2: Fluxo OAuth authorization code

Fonte: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

A Figura 2.2 ilustra o fluxo do authorization Ccde grant, cujos passos são descritos a seguir:

No passo 1, o client inicia o fluxo ao redirecionar o user-agent do resource owner para o authorization server. Nessa requisição de redirecionamento, o client informa sua identificação, os scopes solicitados e uma URI de redirecionamento que o authorization serverirá enviar para o user-agent de volta quando o acesso for concedido (ou negado).

No passo 2, o authorization server autentica o resource owner através do user-agent, e estabelece se o resource owner concedeu ou não a requisição de acesso do client.

CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 18

No passo 3, uma vez que o resource owner concedeu o acesso, o authorization ser- ver redireciona o user-agent de volta para o client usando a URI de redirecionamento fornecida no passo 1. Essa URI inclui um authorization code.

Os passos anteriores (1, 2 e 3) referem-se à requisição de autorização. Vamos agora explicar mais tecnicamente tal processo: a requisição de redirecionamento é realizada através de uma requisição GET ao authorization server, feita com uma URI que é cons- truída pelo client utilizando o formato “application/x-www-form-urlencoded”. Ela tem os seguintes parâmetros:

• response_type

obrigatório e deve ter o valor code por se tratar do authorization code grant;

• client_id

obrigatório e refere-se à identificação do client;

• redirect_uri

opcional e refere-se à URI de redirecionamento mencionada anteriormente.

• scope

opcional e refere-se aos scopes solicitados pelo client em relação aos recursos pro- tegidos do resource owner;

• state

opcional, com o propósito de manter o estado entre a requisição e a resposta, sendo importante para que o resource owner tenha a experiência mais fluida.

Abaixo segue um exemplo dessa requisição de redirecionamento ao authorization ser- ver“authserver.com”: GET https://authserver.com/authorize? response_type=code& client_id=s6BhdRkqt3& state=xyz& redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Ao receber a requisição (passo 1), o authorization server a valida e assegura que todos os parâmetros requeridos estão presentes e válidos. Se a requisição for válida, o authorization server autentica o resource owner e recebe do resource owner se ele autoriza ou não o pedido de acesso do client (passo 2).

Após isso, o authorization server direciona o user-agent para a URI informada em redirect_uri usando uma resposta HTTP de redirecionamento, que inclui o authoriza- tion code(passo 3). A resposta do authorization server para o client vem na forma de uma requisição do primeiro para o segundo. Essa requisição também utiliza o formato “application/x-www-form-urlencoded” e tem os seguintes parâmetros:

CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 19

• code

obrigatório e refere-se ao authorization code gerado pelo authorization server;

• state

obrigatório se o parâmetro state estava presente na requisição de autorização do client(ilustrada anteriormente).

Abaixo segue um exemplo dessa requisição do authorization server para client:

GET https://client.com/endpoit/? code=SplxlOBeZQQYbYS6WxSbIA& state=xyz

No passo 4, o client requisita (informando o authorization code recebido no passo 3) o access token ao authorization server. Ao fazer essa requisição, o client autentica com o authorization server e informa a URI de redirecionamento usada para obter o authorization codepara verificação.

Essa requisição do access token ao resource server pelo client utiliza o formato “application/x- www-form-urlencoded” e tem os seguintes parâmetros:

• grant_type

obrigatório e deve ser authorization_code;

• code

obrigatório e refere-se ao authorization code recebido anteriormente do authoriza- tion server;

• redirect_uri

obrigatório se o redirect_uri foi incluído no authorization request, de forma que tais valores devem ser idênticos;

• client_id

obrigatório e refere-se à identificação do client.

Abaixo segue um exemplo dessa requisição:

POST /token HTTP/1.1 Host: server.example.com

Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code& code=SplxlOBeZQQYbYS6WxSbIA&

CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 20

Ao receber a requisição, o authorization server deve:

• Exigir autenticação do client se for confidential ou se o authorization grant type for client credentials;

• Autenticar o client caso as credenciais de autenticação estejam corretas;

• Caso o client seja confidential, assegurar que o authorization code foi emitido para o client; caso o client seja public, assegurar que o code foi emitido para o client_idda requisição;

• Verificar se o authorization code é valido;

• Assegurar que o parâmetro redirect_uri foi incluído no authorization request inicial e se os valores são idênticos.

No passo 5, o authorization server autentica o client, valida o authorization code e assegura que a URI de redirecionamento é compatível com a URI usada para redirecionar o client no passo 3. Se for válida, o authorization server responde de volta com o access token.

Abaixo segue uma resposta de sucesso com o access token:

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }

Observamos que a resposta vem em formato Javascript Object Notation (JSON) e que o valor do access token está presente no atributo access_token. Além deste, podemos ter atributos extras definidos a critério do desenvolvedor.