Receber tokens do OAuth 2.0

Esta página se aplica à Apigee e à Apigee híbrida.

Confira a documentação da Apigee Edge.

Neste documento, mostramos como receber tokens de acesso e códigos de autorização do OAuth 2.0 com a API Apigee. Também mostramos como criar políticas para cada tipo de concessão do OAuth 2.0 e configurar endpoints de proxy para aceitar solicitações de clientes.

Usar o tipo de concessão de código de autorização

Nesta seção, explicamos como receber um token de acesso usando o fluxo de tipo de concessão do código de autorização. A solicitação de token para este fluxo requer um código de autorização. Consulte Receber um código de autorização. Veja também O que são os tipos de concessão do OAuth 2.0.

Exemplo de solicitação

curl -i -H 'Content-Type: application/x-www-form-urlencoded' \
   -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
   -X POST 'https://apitest.acme.com/oauth/token' \
   -d 'code=I9dMGHAN&grant_type=authorization_code&redirect_uri=http://example-callback.com'

Parâmetros obrigatórios

Por padrão, esses parâmetros precisam ser x-www-form-urlencoded e estar especificados no corpo da solicitação (conforme mostrado no exemplo acima). No entanto, é possível alterar esse padrão configurando os elementos <GrantType>, <Code> e <RedirectUri> na política do OAuthV2. Consulte a política do OAuthV2.

  • grant_type: precisa ser definido como o valor authorization_code.
  • code: o código de autorização. Consulte Como solicitar um código de autorização.
  • redirect_uri: será preciso fornecer esse parâmetro se o parâmetro redirect_uri tiver sido incluído na solicitação do código de autorização. Se o parâmetro redirect_uri não foi incluído na solicitação do código de autorização e se você não o fornecer, essa política usará o valor do URL de callback fornecido no app do desenvolvedor registrado.

Parâmetros opcionais

  • state: uma string que será enviada de volta com a resposta. Usado normalmente para evitar ataques de falsificação de solicitação entre sites.
  • scope: permite filtrar a lista de produtos da API com que o token criado pode ser usado. Para informações detalhadas sobre escopo, consulte Como trabalhar com escopos do OAuth2.

Autorização

Transmita o ID e a chave secreta do cliente como um cabeçalho de autenticação básica (codificado em Base64) ou como parâmetros de formulário client_id e client_secret. Você recebe esses valores de um app do desenvolvedor registrado. Veja também Como codificar credenciais de autenticação básica.

Endpoint de amostra

Veja um exemplo de configuração de endpoint para gerar um token de acesso. Ele executará a política GenerateAccessToken, que precisa ser configurada para aceitar o tipo de autorização authorization_code.

...
       <Flow name="generate-access-token">
            <Description>Generate a token</Description>
            <Request>
                <Step>
                    <Name>GenerateAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/token") and (request.verb = "POST")</Condition>
        </Flow>
...

Exemplo de política

Essa é uma política GenerateAccessToken básica configurada para aceitar o tipo de concessão authorization_code. Para mais informações sobre elementos de configuração opcionais que podem ser configurados com essa política, consulte a Política do OAuthV2 (em inglês).

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn>
    <RefreshTokenExpiresIn>86400000</RefreshTokenExpiresIn>
    <SupportedGrantTypes>
      <GrantType>authorization_code</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Retorna

Com o <GenerateResponse> ativado, a política retorna uma resposta JSON que inclui o token de acesso, conforme mostrado abaixo. O tipo de concessão authorization_code cria um token de acesso e um token de atualização. Assim, uma resposta pode ter a seguinte aparência:

{
    "issued_at": "1420262924658",
    "scope": "READ",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "refresh_token_issued_at": "1420262924658",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799", //--in seconds
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "refresh_token": "fYACGW7OCPtCNDEnRSnqFlEgogboFPMm",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "2l4IQtZXbn5WBJdL6EF7uenOWRsi",
    "organization_name": "docs",
    "refresh_token_expires_in": "86399", //--in seconds
    "refresh_count": "0"
}

Se <GenerateResponse> for definido como falso, a política não retornará uma resposta. Em vez disso, ele preenche o seguinte conjunto de variáveis de fluxo com dados relativos à concessão do token de acesso.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token
oauthv2accesstoken.{policy-name}.refresh_token_expires_in //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token_issued_at
oauthv2accesstoken.{policy-name}.refresh_token_status

Exemplo:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token
oauthv2accesstoken.GenerateAccessToken.refresh_token_expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token_issued_at
oauthv2accesstoken.GenerateAccessToken.refresh_token_status

Usar o tipo de concessão de credenciais do cliente

Nesta seção, explicamos como receber um token de acesso usando o fluxo de tipos de concessão de credenciais do cliente. Veja também O que são os tipos de concessão do OAuth 2.0.

Exemplo de solicitação

curl -H "Content-Type: application/x-www-form-urlencoded" \
  -H "Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ" \
  -X POST "https://apitest.acme.com/oauth/token" \
  -d "grant_type=client_credentials"

Parâmetros obrigatórios

  • grant_type: precisa ser definido como o valor client_credentials.

    Por padrão, o parâmetro obrigatório grant_type precisa ser x-www-form-urlencoded e estar especificado no corpo da solicitação (como mostrado no exemplo acima). No entanto, é possível alterar esse padrão configurando o elemento <GrantType> na política do OAuthV2. Por exemplo, é possível optar por passar o parâmetro em um parâmetro de consulta. Veja mais detalhes em Política do OAuthV2.

Parâmetros opcionais

  • state: uma string que será enviada de volta com a resposta. Usado normalmente para evitar ataques de falsificação de solicitação entre sites.
  • scope: permite filtrar a lista de produtos da API com que o token criado pode ser usado. Para informações detalhadas sobre escopo, consulte Como trabalhar com escopos do OAuth2.

Autorização

Transmita o ID e a chave secreta do cliente como um cabeçalho de autenticação básica (codificado em Base64) ou como parâmetros de formulário client_id e client_secret. Você recebe esses valores do aplicativo do desenvolvedor registrado associado à solicitação. Veja também Como codificar credenciais básicas de autenticação.

Endpoint de amostra

Veja um exemplo de configuração de endpoint para gerar um token de acesso. Ele executará a política GenerateAccessToken, que precisa ser configurada para aceitar o tipo de autorização client_credentials.

...
       <Flow name="generate-access-token">
            <Request>
                <Step>
                    <Name>GenerateAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/token") and (request.verb = "POST")</Condition>
        </Flow>
...

Exemplo de política

Essa é uma política GenerateAccessToken básica configurada para aceitar o tipo de concessão client_credentials. Para mais informações sobre elementos de configuração opcionais que podem ser configurados com essa política, consulte a Política do OAuthV2 (em inglês).

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <SupportedGrantTypes>
      <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Retorna

Com <GenerateResponse> ativado, a política retorna uma resposta JSON. Observe que, com o tipo de concessão client_credentials, os tokens de atualização não são compatíveis. Somente um token de acesso é criado. Exemplo:

{
    "issued_at": "1420260525643",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "scope": "READ",
    "status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799", //--in seconds
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "XkhU2DFnMGIVL2hvsRHLM00hRWav",
    "organization_name": "docs"
}

Se <GenerateResponse> for definido como falso, a política não retornará uma resposta. Em vez disso, ele preenche o seguinte conjunto de variáveis de fluxo com dados relativos à concessão do token de acesso.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in //--in seconds

Exemplo:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in     //--in seconds

Usar o tipo de concessão de senha

Nesta seção, explicamos como receber um token de acesso usando o fluxo de tipo de concessão de credenciais de senha (senha) do proprietário do recurso. Consulte também Como implementar o tipo de concessão da senha. Veja também O que são os tipos de concessão do OAuth 2.0.

Exemplo de solicitação

curl -v -k -H "Content-Type: application/x-www-form-urlencoded" \
  -H "Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ" \
  -X POST "https://apitest.acme.com/oauth/token" \
  -d "grant_type=password&username=a_username&password=a_password"

Parâmetros obrigatórios

Por padrão, esses parâmetros precisam ser x-www-form-urlencoded e estar especificados no corpo da solicitação (conforme mostrado no exemplo acima). No entanto, é possível alterar esse padrão configurando os elementos <GrantType>, <Username> e <Password> na política do OAuthV2. Consulte a política do OAuthV2.

As credenciais de usuário normalmente são validadas em um armazenamento de credenciais usando uma política de LDAP ou JavaScript.

  • grant_type: precisa ser definido como o valor password.
  • username: nome do usuário do proprietário do recurso
  • password: a senha do proprietário do recurso.

Parâmetros opcionais

  • state: uma string que será enviada de volta com a resposta. Usado normalmente para evitar ataques de falsificação de solicitação entre sites.
  • scope: permite filtrar a lista de produtos da API com que o token criado pode ser usado. Para informações detalhadas sobre escopo, consulte Como trabalhar com escopos do OAuth2.

Autorização

Transmita o ID e a chave secreta do cliente como um cabeçalho de autenticação básica (codificado em Base64) ou como parâmetros de formulário client_id e client_secret. Você recebe esses valores do aplicativo do desenvolvedor registrado associado à solicitação. Veja também Como codificar credenciais básicas de autenticação.

Endpoint de amostra

Veja um exemplo de configuração de endpoint para gerar um token de acesso. Ele executará a política GenerateAccessToken, que precisa ser configurada para aceitar o tipo de concessão de senha.

...
       <Flow name="generate-access-token">
            <Request>
                <Step>
                    <Name>GenerateAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/token") and (request.verb = "POST")</Condition>
        </Flow>
...

Exemplo de política

Esta é uma política GenerateAccessToken configurada básica para aceitar o tipo de concessão da senha. Para mais informações sobre elementos de configuração opcionais que podem ser configurados com essa política, consulte a Política do OAuthV2.

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <RefreshTokenExpiresIn>28800000</RefreshTokenExpiresIn> <!-- 8 hours -->
    <SupportedGrantTypes>
      <GrantType>password</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Retorna

Com <GenerateResponse> ativado, a política retorna uma resposta JSON. Observe que tanto os tokens de acesso como os de atualização são criados com o tipo de concessão de senha. Por exemplo:

{
    "issued_at": "1420258685042",
    "scope": "READ",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "refresh_token_issued_at": "1420258685042",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799", //--in seconds
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6",
    "organization_name": "docs",
    "refresh_token_expires_in": "28799", //--in seconds
    "refresh_count": "0"
}

Se <GenerateResponse> for definido como falso, a política não retornará uma resposta. Em vez disso, ele preenche o seguinte conjunto de variáveis de fluxo com dados relativos à concessão do token de acesso.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in   //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token
oauthv2accesstoken.{policy-name}.refresh_token_expires_in  //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token_issued_at
oauthv2accesstoken.{policy-name}.refresh_token_status

Exemplo:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token
oauthv2accesstoken.GenerateAccessToken.refresh_token_expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token_issued_at
oauthv2accesstoken.GenerateAccessToken.refresh_token_status

Usar o tipo de concessão implícita

Nesta seção, explicamos como receber um token de acesso usando o fluxo do tipo de concessão implícito. Veja também O que são os tipos de concessão do OAuth 2.0.

Exemplo de solicitação

$ curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \
  'https://apitest.acme.com/oauth/implicit?response_type=token&client_id=c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ&redirect_uri=http://callback-example.com'

Parâmetros obrigatórios

Por padrão, esses parâmetros precisam ser parâmetros de consulta (conforme mostrado no exemplo acima). No entanto, é possível alterar esse padrão configurando os elementos <ResponseType>, <ClientId> e <RedirectUri> na política OAuthV2 anexada a esse endpoint /token. Veja mais detalhes em Política do OAuthV2.

As credenciais de usuário geralmente são validadas em relação a um armazenamento de credenciais usando uma chamada de serviço LDAP ou uma política JavaScript.

  • response_type: precisa ser definido como o valor token.
  • client_id: o ID do cliente de um aplicativo do desenvolvedor registrado.
  • redirect_uri: este parâmetro será obrigatório se um URI de callback não tiver sido fornecido quando o app desenvolvedor do cliente tiver sido registrado. Se um URL de retorno de chamada foi fornecido no registro do cliente, ele será comparado a esse valor e precisará corresponder exatamente.

Parâmetros opcionais

  • state: uma string que será enviada de volta com a resposta. Usado normalmente para evitar ataques de falsificação de solicitação entre sites.
  • scope: permite filtrar a lista de produtos da API com que o token criado pode ser usado. Para informações detalhadas sobre escopo, consulte Como trabalhar com escopos do OAuth2.

Autorização

Não requer o cabeçalho de autorização. No entanto, você precisa transmitir um ID do cliente como um parâmetro de solicitação.

Endpoint de amostra

Veja um exemplo de configuração de endpoint para gerar um token de acesso. Ele executará a política GenerateAccessTokenImplicitGrant.

...
       <Flow name="generate-access-token-implicit">
            <Request>
                <Step>
                    <Name>GenerateAccessTokenImplicitGrant</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/implicit") and (request.verb = "POST")</Condition>
        </Flow>
...

Exemplo de política

Trata-se de uma política básica de GenerateAccessTokenExplicitGrant que processa solicitações de token para o fluxo de tipo de concessão implícito. Para mais informações sobre elementos de configuração opcionais que podem ser configurados com essa política, consulte a Política do OAuthV2.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 name="GenerateAccessTokenImplicit">
    <DisplayName>GenerateAccessTokenImplicit</DisplayName>
    <Operation>GenerateAccessTokenImplicitGrant</Operation>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Retorna

Com <GenerateResponse> ativado, a política retorna um redirecionamento 302 no cabeçalho da resposta. O redirecionamento aponta para o URL especificado no parâmetro redirect_uri e é anexado ao token de acesso e ao prazo de validade do token. Observe que o tipo de concessão implícito não é compatível com tokens de atualização. Exemplo:

https://callback-example.com#expires_in=1799&access_token=In4dKm4ueoGZRbIYJhC9yZCmTFw5

Se <GenerateResponse> for definido como falso, a política não retornará uma resposta. Em vez disso, ele preenche o seguinte conjunto de variáveis de fluxo com dados relativos à concessão do token de acesso.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in  //--in seconds

Exemplo:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in   //--in seconds

Receber um código de autorização

No fluxo do tipo de concessão do código de autorização, um código de autorização é necessário para conseguir um token de acesso. Consulte Usar o tipo de concessão de código de autorização. Veja também O que são os tipos de concessão do OAuth 2.0.

Exemplo de solicitação

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" \
  "https://apitest.acme.com/oauth/authorize?response_type=code&client_id=c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ&redirect_uri=http://my-callback.com"

Parâmetros obrigatórios

Por padrão, esses parâmetros precisam ser parâmetros de consulta (como exibido no exemplo acima). No entanto, é possível alterar esse padrão configurando os elementos <ResponseType>, <ClientId> e <RedirectUri> na política do OAuthV2. Veja mais detalhes em Política do OAuthV2.

  • redirect_uri: se um URI de callback completo (não parcial) for especificado no app cliente registrado, esse parâmetro será opcional. caso contrário, será obrigatório. O callback é o URL para onde o Edge envia o código de autenticação recém-criado. Consulte também Registrar apps e gerenciar chaves de API.
  • response_type: precisa ser definido como o valor code.
  • client_id: o ID do cliente de um aplicativo do desenvolvedor registrado.

Parâmetros opcionais

  • redirect_uri: se um URI de callback completo (não parcial) for especificado no app cliente registrado, esse parâmetro será opcional. caso contrário, será obrigatório. O callback é o URL para onde o Edge envia o código de autenticação recém-criado. Consulte também Registrar apps e gerenciar chaves de API.
  • state: uma string que será enviada de volta com a resposta. Usado normalmente para evitar ataques de falsificação de solicitação entre sites.
  • scope: permite filtrar a lista de produtos da API com que o token criado pode ser usado. Para informações detalhadas sobre escopo, consulte Como trabalhar com escopos do OAuth2.

Autorização

Não requer o cabeçalho Authorization. No entanto, o ID do aplicativo cliente registrado precisa ser fornecido na solicitação.

Exemplo de política

Esta é uma política geral de GenerateAuthorizationCode. Para mais opções de configuração, consulte a Política do OAuthV2:

<OAuthV2 name="GenerateAuthorizationCode">
    <Operation>GenerateAuthorizationCode</Operation>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Retorna

Com <GenerateResponse> ativado, a política retorna o parâmetro de consulta ?code para o local redirect_uri (URI de callback) com o código de autorização anexado. Ele é enviado por meio de um redirecionamento 302 do navegador com o URL no cabeçalho de localização da resposta. Exemplo: ?code=123456.

Se <GenerateResponse> estiver definido como false, a política não retornará uma resposta. Em vez disso, ele preenche o seguinte conjunto de variáveis de fluxo com dados relacionados ao código de autorização.

oauthv2authcode.{policy-name}.code
oauthv2authcode.{policy-name}.scope
oauthv2authcode.{policy-name}.redirect_uri
oauthv2authcode.{policy-name}.client_id

Exemplo:

oauthv2authcode.GenerateAuthorizationCode.code
oauthv2authcode.GenerateAuthorizationCode.scope
oauthv2authcode.GenerateAuthorizationCode.redirect_uri
oauthv2authcode.GenerateAuthorizationCode.client_id

Atualização do token de acesso

Um token de atualização é uma credencial que você usa para conseguir um token de acesso, geralmente depois que o token de acesso expirou ou se torna inválido. Um token de atualização é retornado na resposta quando você recebe um token de acesso.

Exemplo de solicitação

Para informações sobre como codificar o cabeçalho de autenticação básica na chamada a seguir, consulte Como codificar credenciais de autenticação básica. 

$ curl -X POST \
  -H "Content-type: application/x-www-form-urlencoded" \
  -H "Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ" \
  https://apitest.acme.com/oauth/refresh \
  -d "grant_type=refresh_token&refresh_token=yVSL38WpuN3Kzn1UTMoE6AQ4ANZM"

Parâmetros obrigatórios

Por padrão, a política procura esses parâmetros como x-www-form-urlencoded especificados no corpo da solicitação, como mostrado no exemplo acima. Para configurar um local alternativo para essas entradas, use os elementos <GrantType> e <RefreshToken> na política OAuthV2. Veja mais detalhes em Política do OAuthV2.

  • grant_type: precisa ser definido como o valor refresh_token.
  • refresh_token: o token de atualização associado ao token de acesso que você quer renovar.

Parâmetros opcionais

  • state: uma string que será enviada de volta com a resposta. Usado normalmente para evitar ataques de falsificação de solicitação entre sites.
  • scope: permite filtrar a lista de produtos da API com que o token criado pode ser usado. Para informações detalhadas sobre escopo, consulte Como trabalhar com escopos do OAuth2.

Autorização

Não requer o cabeçalho Authorization. No entanto, o ID do aplicativo cliente registrado precisa ser fornecido na solicitação.

Ao atualizar um token de acesso, não há uma nova autenticação do usuário.

Veja um exemplo de configuração de endpoint para gerar um token de acesso usando um token de atualização. Ele executará a política RefreshAccessToken.

 ...
       <Flow name="generate-refresh-token">
            <Request>
                <Step>
                    <Name>RefreshAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/refresh") and (request.verb = "POST")</Condition>
       </Flow>
...

Exemplo de política

Esta é uma política RefreshAccessToken básica configurada para aceitar o tipo de concessão refresh_token. Para mais informações sobre os elementos de configuração opcionais que podem ser configurados com essa política, consulte a política do OAuthV2.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 name="RefreshAccessToken">
    <Operation>RefreshAccessToken</Operation>
    <GenerateResponse enabled="true"/>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <RefreshTokenExpiresIn>28800000</RefreshTokenExpiresIn> <!-- 8 hours -->
</OAuthV2>

Retorna

Com <GenerateResponse> ativado, a política retorna uma resposta JSON que contém o novo token de acesso. O tipo de concessão refresh_token é compatível com a redução de acessos e novos tokens de atualização. Exemplo:

{
    "issued_at": "1420301470489",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "scope": "READ",
    "refresh_token_issued_at": "1420301470489",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799", //--in seconds
    "developer.email": "tesla@weathersample.com",
    "token_type": "BearerToken",
    "refresh_token": "8fKDHLryAD9KFBsrpixlq3qPJnG2fdZ5",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "jmZ2Hqv3iNsABUtAAsfWR3QGNctw",
    "organization_name": "docs",
    "refresh_token_expires_in": "28799", //--in seconds
    "refresh_count": "2"
}

Você precisa saber que, depois que um novo token de atualização é criado, o original não é mais válido.

A resposta acima é o que você receberá se <GenerateResponse> estiver definido como verdadeiro. Se <GenerateResponse> for definido como falso, a política não retornará uma resposta. Em vez disso, ele preenche o seguinte conjunto de variáveis de contexto (fluxo) com dados relacionados à concessão do token de acesso.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in   //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token
oauthv2accesstoken.{policy-name}.refresh_token_expires_in  //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token_issued_at
oauthv2accesstoken.{policy-name}.refresh_token_status

Exemplo:

oauthv2accesstoken.RefreshAccessToken.access_token
oauthv2accesstoken.RefreshAccessToken.expires_in
oauthv2accesstoken.RefreshAccessToken.refresh_token
oauthv2accesstoken.RefreshAccessToken.refresh_token_expires_in
oauthv2accesstoken.RefreshAccessToken.refresh_token_issued_at
oauthv2accesstoken.RefreshAccessToken.refresh_token_status

Como codificar credenciais de autenticação básica

Ao fazer uma chamada de API para solicitar um token ou código de autenticação, uma prática recomendada pela especificação do OAuth 2.0 é transmitir os valores client_id e client_secret como um cabeçalho de autorização HTTP-Basic, conforme descrito no IETF RFC 2617. Para fazer isso, é preciso codificar o resultado em base64 com dois valores separados por dois pontos.

Em pseudocódigo:

result = Base64Encode(concat('ns4fQc14Zg4hKFCNaSzArVuwszX95X', ':', 'ZIjFyTsNgQNyxI'))

Em que: ns4fQc14Zg4hKFCNaSzArVuwszX95X é o client_id e ZIjFyTsNgQNyxI é a chave secreta do cliente.

Exemplos

Este exemplo de comando funciona no Linux e no MacOS:

export CREDENTIALS=$(echo -n 'ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI' | base64)

Em seguida, é possível fazer a solicitação de token da seguinte maneira:

$ curl -i -H "Content-Type: application/x-www-form-urlencoded" \
  -H "Authorization: Basic $CREDENTIALS" \
  -X POST "https://apitest.acme.com/oauth/token" \
  -d "grant_type=client_credentials"

Tokens de hash no banco de dados

A Apigee gera hash de todos os tokens de acesso e atualização do OAuth para protegê-los em caso de violação de segurança do banco de dados. Você usa tokens sem hash em chamadas de API, e a Apigee valida esses tokens em relação às versões com hash do banco de dados.

Temas relacionados