Política do OAuthV2

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

Confira a documentação da Apigee Edge.

No momento, o recurso de token de acesso JWT está disponível para a Apigee e para a Apigee híbrida, versões 1.7.0 e mais recentes. Consulte Como usar tokens OAuth do JWT.

O que

OAuthV2 é uma política multifacetada para executar operações do tipo de concessão OAuth 2.0. Essa é a política principal usada para configurar endpoints OAuth 2.0 na Apigee.

Esta é uma política extensível. O uso dela pode ter implicações no custo ou na utilização, dependendo da sua licença da Apigee. Para informações sobre tipos de política e implicações de uso, consulte Tipos de política.

Para saber mais sobre o OAuth na Apigee, consulte a página inicial do OAuth. Ela fornece links para recursos, amostras, vídeos e muito mais.

Dica: consulte a política VerifyIAM para conferir uma política padrão que oferece um método integrado do IAM do Google Cloud para gerenciar a autenticação e autorização em um proxy.

Amostras

VerifyAccessToken

VerifyAccessToken

Essa configuração de política OAuthV2 (com a operação VerifyAccessToken) verifica se um token de acesso enviado à Apigee é válido. Quando essa operação de política é acionada, a Apigee procura um token de acesso válido na solicitação. Se o token de acesso for válido, a solicitação poderá continuar. Se inválido, todos os processamentos serão interrompidos e um erro será retornado na resposta.

<OAuthV2 name="OAuthV2-Verify-Access-Token">
    <Operation>VerifyAccessToken</Operation>
</OAuthV2>

Observação: só os tokens do portador do OAuth 2.0 são compatíveis. Outros tipos de tokens, como os de código de autenticação de mensagem (MAC, na sigla em inglês), não são compatíveis.

Um aplicativo cliente precisa enviar uma solicitação com um token. Por exemplo, o uso de curl pode ser:

$ curl https://API_ENDPOINT/weather/forecastrss?w=12797282 \
  -H "Authorization: Bearer ylSkZIjbdWybfsUQe9BqP0LH5Z"

Em que API_ENDPOINT é o domínio usado para acessar suas APIs, conforme configurado no seu sistema da Apigee.

Por padrão, a política OAuthV2 extrai o token de acesso do cabeçalho Authorization, removendo o prefixo Bearer. É possível alterar esse comportamento padrão com o elemento de configuração AccessToken.

GenerateAccessToken

Como gerar tokens de acesso

Para ver exemplos de como solicitar tokens de acesso para cada um dos tipos de concessão compatíveis, consulte Receber tokens do OAuth 2.0. O tópico inclui exemplos dessas operações:

• Código de autorização
• Credenciais do cliente
• Implícito
• Senha

Observação: a política do OAuthV2 retorna determinados elementos de resposta não compatíveis com a RFC. Por exemplo, a política retorna uma propriedade de token, "token_type":"BearerToken", em que a propriedade do token compatível é "token_type":"Bearer". Para detalhes sobre esses elementos de resposta não compatíveis, consulte Comportamento não compatível com a RFC.

GenerateAuthorizationCode

Gerar código de autorização

Para ver exemplos de como solicitar códigos de autorização, consulte Como solicitar um código de autorização.

RefreshAccessToken

Atualizar um token de acesso

Para exemplos de como solicitar tokens de acesso usando um token de atualização, consulte Como atualizar um token de acesso.

Tokens de acesso JWT

Tokens de acesso JWT

Para exemplos de como gerar, verificar e atualizar tokens de acesso JWT, consulte Como usar tokens de acesso JWT.

Token de fluxo de resposta

Gerar um token de acesso no fluxo de resposta

Às vezes, pode ser necessário gerar um token de acesso no fluxo de resposta. Por exemplo, é possível fazer isso em resposta a uma validação personalizada feita em um serviço de back-end. Neste exemplo, o caso de uso requer um token de acesso e um token de atualização, considerando o tipo de concessão implícito. Nesse caso, usaremos o tipo de concessão de senha para gerar o token. Como você verá, o truque para fazer isso funcionar é passar um cabeçalho de solicitação de autorização com uma política JavaScript.

Primeiro, vamos analisar a política de exemplo:

<OAuthV2 enabled="true" continueOnError="false" async="false" name="generateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <AppEndUser>Doe</AppEndUser>
    <UserName>jdoe</UserName>
    <PassWord>jdoe</PassWord>
    <GrantType>grant_type</GrantType>
    <ClientId>a_valid_client_id</ClientId>
    <SupportedGrantTypes>
        <GrantType>password</GrantType>
    </SupportedGrantTypes>
</OAuthV2>

Se você colocar essa política no fluxo de resposta, ela falhará com um erro 401 UnAuthorized, mesmo que os parâmetros de login corretos sejam especificados na política. Para resolver esse problema, é preciso definir um cabeçalho de solicitação de autorização.

O cabeçalho de autorização precisa conter um esquema de acesso básico com o client_id codificado em Base64:client_secret.

É possível adicionar esse cabeçalho com uma política JavaScript colocada antes da política OAuthV2, como esta. As variáveis de contexto "local_clientid" e "local_secret" precisam ser definidas e disponíveis anteriormente no fluxo:

var clientId = context.getVariable("local_clientid");
var clientSecret = context.getVariable("local_secret");
context.setVariable("request.header.Authorization","Basic "+ CryptoJS.enc.Base64.stringify(CryptoJS.enc.Latin1
                                      .parse(clientId + ':' + clientSecret)));

Veja também Como codificar credenciais básicas de autenticação.

Referência de elemento

A referência de política descreve os elementos e atributos da política OAuthV2.

Observação: a maneira como você configura esta política e os elementos que precisa especificar, dependem da operação que será executada pela política. Por exemplo, se você estiver implementando o tipo de concessão do código de autorização, precisará de quatro políticas OAuthV2 separadas para realizar a geração de código de autorização, geração de código de acesso, validação de código de acesso e a geração do token de atualização. Essa referência lista todos os elementos que podem ser usados com essa política.

Se você quiser ver configurações para casos de uso específicos de tipo de concessão, consulte a página inicial do OAuth para uma lista de implementações de tipos de concessão.

A política de amostra mostrada abaixo é uma das configurações possíveis. Este exemplo mostra uma política do OAuthV2 configurada para a operação GenerateAccessToken. Ele inclui elementos obrigatórios e opcionais. Consulte as descrições dos elementos nesta seção para mais detalhes.

<OAuthV2 name="GenerateAccessToken">
  <!-- This policy generates an OAuth 2.0 access token using the client_credentials grant type -->
  <Operation>GenerateAccessToken</Operation>
  <!-- This is in millseconds, so expire in an hour -->
  <ExpiresIn>3600000</ExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.queryparam.grant_type</GrantType>
  <GenerateResponse/>
</OAuthV2>

Atributos de <OAuthV2>

<OAuthV2 async="false" continueOnError="false" enabled="true" name="MyOAuthPolicy">

A tabela a seguir descreve atributos comuns a todos os elementos pai de políticas:

Atributo	Descrição	Padrão	Presence
name	O nome interno da política. O valor do atributo name pode conter letras, números, espaços, hifens, sublinhados e pontos. Esse valor não pode exceder 255 caracteres. Opcionalmente, use o elemento <DisplayName> para rotular a política no editor de proxy da IU de gerenciamento com um nome de linguagem natural diferente.	N/A	Obrigatório
continueOnError	Defina como false para retornar um erro quando uma política falhar. Esse é o comportamento esperado na maioria das políticas. Defina como true para que a execução do fluxo continue mesmo depois que uma política falhar. Consulte também: As regras de falha são acionadas SOMENTE em um estado de erro (sobre continueOnError) Como corrigir falhas no fluxo atual	false	Opcional
enabled	Defina como true para aplicar a política. Defina como false para desativar a política. A política não será aplicada mesmo se ela permanecer anexada a um fluxo.	true	Opcional
async	Esse atributo está obsoleto.	false	Descontinuado

Elemento <DisplayName>

Use em conjunto com o atributo name para rotular a política no editor de proxy da IU de gerenciamento com um nome de linguagem natural diferente.

<DisplayName>Policy Display Name</DisplayName>

Padrão	N/A Se você omitir esse elemento, será usado o valor do atributo name da política.
Presence	Opcional
Tipo	String

Elemento <AccessToken>

<AccessToken>request.header.access_token</AccessToken>

Por padrão, quando Operation é VerifyAccessToken, a política espera que o token de acesso seja enviado no cabeçalho Authorization como um token do portador; ou seja, com um prefixo "Bearer" seguido por um espaço em branco. É possível alterar esse padrão usando esse elemento, especificando o nome de uma variável que contém o token de acesso a ser verificado. Quando você usa esse elemento, a política por padrão não procura um prefixo no conteúdo da variável. Se você quiser especificar que a política precisa procurar um prefixo, use também o elemento AccessTokenPrefix.

Exemplos:

• Quando a configuração da política for:

    <OAuthV2 name="OAuthV2-Verify-Access-Token-in-Header">
        <Operation>VerifyAccessToken</Operation>
        <AccessToken>request.header.access_token</AccessToken>
    </OAuthV2>

  Para transmitir o token usando curl, use:

    curl https://API_ENDPOINT/oauth2/validate -H "access_token:Rft3dqrs56Blirls56a"

• Quando a configuração da política for:

    <OAuthV2 name="OAuthV2-Verify-Access-Token-in-QueryParam">
        <Operation>VerifyAccessToken</Operation>
        <AccessToken>request.queryparam.token</AccessToken>
    </OAuthV2>

  Para transmitir o token usando curl, use:

    curl "https://API_ENDPOINT/oauth2/validate?token=Rft3dqrs56Blirls56a"

Em que API_ENDPOINT é o domínio usado para acessar as APIs, conforme configurado no sistema da Apigee.

Padrão:	N/A
Presença:	Opcional
Tipo:	String
Valores válidos:	qualquer nome de variável
Usado com operações:	VerifyAccessToken

Elemento <AccessTokenPrefix>

<AccessTokenPrefix>Prefix</AccessTokenPrefix>

Por padrão, quando Operation é VerifyAccessToken, a política espera que o token de acesso seja enviado no cabeçalho Authorization como um token do portador; ou seja, com um prefixo "Bearer" seguido por um espaço em branco. Se você usar o elemento AccessToken para especificar um local diferente para o token de acesso de entrada, também será possível usar esse elemento, AccessTokenPrefix, para especificar um prefixo diferente e não padrão.

Por exemplo, se você especificar:

<OAuthV2 name="OAuthV2-Verify-Access-Token-Alternative-Header">
    <Operation>VerifyAccessToken</Operation>
    <AccessToken>request.header.token</AccessToken>
    <AccessTokenPrefix>KEY</AccessTokenPrefix>
</OAuthV2>

Em seguida, a política vai extrair o token de acesso de entrada do cabeçalho de solicitação token desta maneira: se o cabeçalho começar com a palavra "KEY" seguida de um espaço, a política vai retirar esse prefixo e o espaço e interpretar o valor restante como o token de acesso. Se o prefixo especificado não estiver presente no cabeçalho, a política vai gerar uma falha.

Se você especificar o elemento AccessToken e não especificar o elemento AccessTokenPrefix, a política interpretará todo o valor da variável especificada no elemento AccessToken como o token de acesso.

Esse elemento só é eficaz quando o elemento AccessToken também é usado.

Padrão:	Nenhuma
Presença:	Opcional
Tipo:	String
Valores válidos:	Qualquer string.
Usado com operações:	VerifyAccessToken

<Algorithm>

<Algorithm>algorithm-here</Algorithm>

Especifica o algoritmo de criptografia usado para assinar um token de acesso JWT. Os algoritmos RSA (RS*) empregam um par de chaves públicas/secretas, enquanto os algoritmos HMAC (HS*) empregam uma senha secreta. Esse elemento é obrigatório para as operações GenerateJWTAccessToken, VerifyJWTAccessToken e RefreshJWTAccessToken.

Padrão	N/A
Presence	Obrigatório ao usar as operações GenerateJWTAccessToken, VerifyJWTAccessToken e RefreshJWTAccessToken.
Tipo	String
Valores válidos	HS256, HS384, HS512, RS256, RS384, RS512

Elemento <AppEndUser>

<AppEndUser>request.queryparam.app_enduser</AppEndUser>

Nos casos em que o ID do usuário final do aplicativo precisa ser enviado ao servidor de autorização, esse elemento permite especificar onde a Apigee deve procurar o ID do usuário final. Por exemplo, ele pode ser enviado como um parâmetro de consulta ou em um cabeçalho HTTP.

Por exemplo, request.queryparam.app_enduser indica que o AppEndUser precisa estar presente como um parâmetro de consulta, como, por exemplo, ?app_enduser=[e-mail]. Por exemplo, para exigir o AppEndUser em um cabeçalho HTTP, por exemplo, defina esse valor como request.header.app_enduser.

Fornecer essa configuração permite que você inclua um ID de usuário final do aplicativo no token de acesso. Esse recurso é útil se você quiser recuperar ou revogar tokens de acesso do OAuth 2.0 por ID do usuário final. Para mais informações, consulte Ativar a recuperação e a revogação de tokens de acesso do OAuth 2.0 por ID de usuário final, ID do aplicativo ou ambos.

Padrão:	N/A
Presença:	Opcional
Tipo:	String
Valores válidos:	Qualquer variável de fluxo acessível para a política no tempo de execução.
Usado com tipos de concessão:	authorization_code Implícito senha client_credentials

<Attributes/Attribute>

<Attributes>
    <Attribute name="attr_name1" ref="flow.variable" display="true|false">value1</Attribute>
    <Attribute name="attr_name2" ref="flow.variable" display="true|false">value2</Attribute>
</Attributes>

Use esse elemento para adicionar atributos personalizados a um token de acesso ou a códigos de autorização. Por exemplo, talvez você queira incorporar um ID de usuário ou identificador de sessão em um token de acesso que possa ser extraído e verificado no ambiente de execução.

Esse elemento permite especificar um valor em uma variável de fluxo ou de uma string literal. Se você especificar uma variável e uma string, o valor especificado na variável de fluxo será usado. Se a variável não puder ser resolvida, a string será o padrão.

Para mais informações sobre como usar esse elemento, consulte Como personalizar tokens e códigos de autorização.

Observações:

Você pode criar até 18 atributos personalizados.

Se você adicionar atributos personalizados a um código de autorização, eles serão herdados pelo token de acesso gerado a partir desse código.

Como exibir ou ocultar atributos personalizados na resposta

Lembre-se de que se você definir o elemento GenerateResponse dessa política como true, a representação JSON completa do token será retornada na resposta, incluindo todos os atributos personalizados que você definir. Em alguns casos, você pode ocultar alguns ou todos os atributos personalizados na resposta para que eles não fiquem visíveis para os apps clientes.

Por padrão, os atributos personalizados aparecem na resposta. Se quiser ocultá-los, defina o parâmetro display como false. Exemplo:

<Attributes>
    <Attribute name="employee_id" ref="employee.id" display="false"/>
    <Attribute name="employee_name" ref="employee.name" display="false"/>
</Attributes>

O valor do atributo display não é mantido. Digamos que você gere um token de acesso com atributos personalizados que quer ocultar na resposta gerada. A definição de display=false atinge essa meta. No entanto, se um novo token de acesso for gerado posteriormente usando um token de atualização, os atributos personalizados originais do token de acesso serão exibidos na resposta do token de atualização. Isso ocorre porque a Apigee não se lembra de que o atributo display foi definido originalmente como false na política de geração de tokens de acesso. O atributo personalizado é simplesmente parte dos metadados do token de acesso.

Você verá o mesmo comportamento se adicionar atributos personalizados a um código de autorização. Quando um token de acesso for gerado usando esse código, esses atributos personalizados serão exibidos na resposta do token de acesso. Novamente, esse pode não ser o comportamento esperado.

Para ocultar atributos personalizados nesses casos, você tem as seguintes opções:

• Redefina explicitamente os atributos personalizados na política de tokens de atualização e defina a exibição deles como "false". Nesse caso, talvez seja necessário recuperar os valores personalizados originais do token de acesso original usando a política GetOAuthV2Info.
• Use uma política JavaScript de pós-processamento para extrair manualmente quaisquer atributos personalizados que você não quer ver na resposta.

Consulte também Como personalizar tokens e códigos de autorização.

Padrão:	N/A
Presença:	Opcional
Valores válidos:	name -O nome do atributo ref - O valor do atributo. Pode vir de uma variável de fluxo. display - (opcional) permite especificar se os atributos personalizados aparecem ou não na resposta. Se for true, os atributos personalizados serão exibidos na resposta (se GenerateResponse também estiver ativado). Se false, os atributos personalizados não serão incluídos na resposta. O valor padrão é true. Consulte Como exibir ou ocultar atributos personalizados na resposta.
Usado com tipos de concessão:	authorization_code Implícito senha client_credentials refresh_token Também pode ser usada com a operação GenerateAuthorizationCode.

Elemento <CacheExpiryInSeconds>

<CacheExpiryInSeconds ref="request.queryparam.cache_expiry">Value 1</CacheExpiryInSeconds>

Esse elemento aplica o TTL no cache, o que permite a personalização do período de validade do token de acesso armazenado em cache. O intervalo suportado está entre 1 e 180 segundos. Você pode fornecer uma variável de fluxo e uma variável padrão. Se fornecido, o valor da variável de fluxo terá prioridade sobre o valor padrão especificado.

Esse elemento pode ser usado apenas com a operação VerifyAccessToken.

Observação: haverá uma queda no desempenho quando o intervalo de armazenamento em cache for reduzido.

Padrão	N/A Se você omitir esse elemento, o período de validade padrão para o token de acesso em cache será de 180 segundos.
Presence	Opcional
Tipo	Número inteiro
Valores válidos	Qualquer número inteiro positivo diferente de zero. Especifica o tempo de expiração em segundos.

Atributos

A tabela a seguir descreve os atributos do elemento <CacheExpiryInSeconds>

Atributo	Descrição	Padrão	Presence
ref	Uma referência à variável de fluxo que contém o valor da expiração do cache, expresso em segundos. Se fornecido, o valor da variável de fluxo terá prioridade sobre o valor padrão especificado.	N/A	Opcional

Elemento <ClientId>

<ClientId>request.formparam.client_id</ClientId>

Em vários casos, o app cliente precisa enviar o ID do cliente para o servidor de autorização. Esse elemento especifica que a Apigee precisa procurar o ID do cliente na variável de fluxo request.formparam.client_id. Não é possível definir ClientId como nenhuma outra variável. Consulte também Receber tokens do OAuth 2.0.

Padrão:	request.formparam.client_id (um x-www-form-urlencoded e especificado no corpo da solicitação)
Presença:	Opcional
Tipo:	String
Valores válidos:	A variável de fluxo: request.formparam.client_id
Usado com tipos de concessão:	authorization_code senha Implícito client_credentials Também pode ser usada com a operação GenerateAuthorizationCode.

Elemento <Code>

<Code>request.queryparam.code</Code>

No fluxo de tipo de concessão de autorização, o cliente precisa enviar um código de autorização ao servidor de autorização (Apigee). Esse elemento permite especificar onde a Apigee deve procurar o código de autorização. Por exemplo, ele pode ser enviado como um parâmetro de consulta, um cabeçalho HTTP ou um parâmetro de formulário (o padrão).

A variável request.queryparam.auth_code indica que o código de autorização deve estar presente como um parâmetro de consulta, como, por exemplo, ?auth_code=AfGlvs9. Para exigir o código de autorização em um cabeçalho HTTP, por exemplo, defina esse valor como request.header.auth_code. Consulte também Receber tokens do OAuth 2.0.

Padrão:	request.formparam.code (um x-www-form-urlencoded e especificado no corpo da solicitação)
Presença:	opcional
Tipo:	String
Valores válidos:	Qualquer variável de fluxo acessível para a política no tempo de execução
Usado com tipos de concessão:	authorization_code

Elemento <ExpiresIn>

<ExpiresIn>10000</ExpiresIn>

Aplica o tempo de expiração dos tokens de acesso e códigos de autorização em milissegundos. Para tokens de atualização, use <RefreshTokenExpiresIn>. O valor do tempo de expiração é um valor gerado pelo sistema mais o valor <ExpiresIn>. Se <ExpiresIn> for definido como -1, o token ou código expirará de acordo com a expiração máxima do token de acesso OAuth. Se <ExpiresIn> não for especificado, o sistema aplicará um valor padrão configurado no nível do sistema.

O tempo de expiração também pode ser definido no tempo de execução usando um valor padrão codificado ou referir-se a uma variável de fluxo. Por exemplo, você pode armazenar um valor de expiração de token em um mapa de chave-valor, recuperá-lo, atribuí-lo a uma variável e referenciá-lo na política. Por exemplo, kvm.oauth.expires_in.

A Apigee mantém as seguintes entidades em cache por pelo menos 180 segundos após serem acessadas.

• Tokens de acesso do OAuth Isso significa que o elemento ExpiresIn na política do OAuth v2 não poderá expirar um token de acesso em menos de 180 segundos.
• Entidades de serviço de gerenciamento de chaves (KMS) (apps, desenvolvedores, produtos de API).
• Atributos personalizados em tokens OAuth e entidades KMS.

A estrofe a seguir especifica também uma variável de fluxo e um valor padrão. Observe que o valor da variável de fluxo tem precedência sobre o valor padrão especificado.

<ExpiresIn ref="kvm.oauth.expires_in">
    3600000 <!--default value in milliseconds-->
</ExpiresIn>

A Apigee não permite uma maneira de forçar a expiração de um token depois que ele foi criado. Se você precisar forçar a expiração de token (por exemplo, com base em uma condição), uma solução possível pode ser descrita nesta postagem da comunidade da Apigee.

Por padrão, os tokens de acesso expirados são limpos do sistema Apigee automaticamente três dias após a expiração. Consulte também Como limpar tokens de acesso

Padrão:	Se não for especificado, o sistema aplicará um valor padrão configurado no nível do sistema.
Presença:	Opcional
Tipo:	Número inteiro
Valores válidos:	Qualquer número inteiro positivo e não zero. Especifique o prazo de validade em milissegundos. Embora o valor desse elemento esteja em milissegundos, o valor definido na propriedade expires_in do token e na variável de fluxo expires_in é expresso em segundos. -1 expirará de acordo com a expiração máxima do token de acesso OAuth. Observação: especificar qualquer outro número inteiro negativo ou zero causa um erro de implantação.
Usado com tipos de concessão:	authorization_code Implícito senha client_credentials refresh_token Também usado com a operação GenerateAuthorizationCode.

Observação: se ExpiresIn estiver definido como -1, você verá o seguinte valor de expiração no token gerado: "expires_in" : "0".

.

Elemento <ExternalAccessToken>

<ExternalAccessToken>request.queryparam.external_access_token</ExternalAccessToken>

Informa à Apigee onde encontrar um token de acesso externo (um token de acesso não gerado pela Apigee).

A variável request.queryparam.external_access_token indica que o token de acesso externo precisa estar presente como um parâmetro de consulta, como, por exemplo, ?external_access_token=12345678. Para exigir o token de acesso externo em um cabeçalho HTTP, por exemplo, defina esse valor como request.header.external_access_token. Consulte também Como usar tokens OAuth de terceiros.

Elemento <ExternalAuthorization>

<ExternalAuthorization>true</ExternalAuthorization>

Se esse elemento for falso ou não presente, a Apigee validará client_id e client_secret normalmente em relação ao armazenamento de autorização da Apigee. Use esse elemento quando quiser trabalhar com tokens OAuth de terceiros. Para detalhes sobre como usar esse elemento, consulte Como usar tokens OAuth de terceiros.

Padrão:	false
Presença:	Opcional
Tipo:	Booleano
Valores válidos:	verdadeiro ou falso
Usado com tipos de concessão:	authorization_code senha client_credentials

Elemento <ExternalAuthorizationCode>

<ExternalAuthorizationCode>request.queryparam.external_auth_code</ExternalAuthorizationCode>

Informa à Apigee onde encontrar um código de autenticação externo (um código de autenticação não gerado pela Apigee).

A variável request.queryparam.external_auth_code indica que o código de autenticação externo deve estar presente como um parâmetro de consulta, como, por exemplo, ?external_auth_code=12345678. Para exigir o código de autenticação externo em um cabeçalho HTTP, por exemplo, defina esse valor como request.header.external_auth_code. Consulte também Como usar tokens OAuth de terceiros.

Elemento <ExternalRefreshToken>

<ExternalRefreshToken>request.queryparam.external_refresh_token</ExternalRefreshToken>

Informa à Apigee onde encontrar um token de atualização externo (um token de atualização não gerado pela Apigee).

A variável request.queryparam.external_refresh_token indica que o token de atualização externo precisa estar presente como um parâmetro de consulta, como, por exemplo, ?external_refresh_token=12345678. Para exigir o token de atualização externo em um cabeçalho HTTP, por exemplo, defina esse valor como request.header.external_refresh_token. Consulte também Como usar tokens OAuth de terceiros.

Elemento <GenerateResponse>

<GenerateResponse enabled='true'/>

Se for definida como true ou se o atributo enabled for omitido, a política vai gerar e retornar uma resposta. Por exemplo, para GenerateAccessToken, a resposta pode ser:

{
  "issued_at" : "1467841035013",
  "scope" : "read",
  "application_name" : "e31b8d06-d538-4f6b-9fe3-8796c11dc930",
  "refresh_token_issued_at" : "1467841035013",
  "status" : "approved",
  "refresh_token_status" : "approved",
  "api_product_list" : "[Product1, nhl_product]",
  "expires_in" : "1799",
  "developer.email" : "[e-mail]",
  "token_type" : "BearerToken",
  "refresh_token" : "rVSmm3QaNa0xBVFbUISz1NZI15akvgLJ",
  "client_id" : "Adfsdvoc7KX5Gezz9le745UEql5dDmj",
  "access_token" : "AnoHsh2oZ6EFWF4h0KrA0gC5og3a",
  "organization_name" : "cerruti",
  "refresh_token_expires_in" : "0",
  "refresh_count" : "0"
}

Se for definido como false ou se o elemento <GenerateResponse> for omitido, nenhuma resposta será enviada. Em vez disso, um conjunto de variáveis de fluxo é preenchido com valores relacionados à função da política. Por exemplo, uma variável de fluxo chamada oauthv2authcode.OAuthV2-GenerateAuthorizationCode.code é preenchida com o código de autenticação recém-criado. Observe que expires_in é expresso em segundos na resposta.

Padrão:	true
Presença:	Opcional
Tipo:	string
Valores válidos:	verdadeiro ou falso
Usado com tipos de concessão:	Implícito senha client_credentials refresh_token Também pode ser usada com a operação GenerateAuthorizationCode.

Elemento <GenerateErrorResponse>

<GenerateErrorResponse enabled='true'/>

Se configurada como true, a política gerará e retornará uma resposta se o atributo ContinueOnError estiver definido como "true". Se false (o padrão), nenhuma resposta será enviada. Em vez disso, um conjunto de variáveis de fluxo é preenchido com valores relacionados à função da política.

Padrão:	false
Presença:	Opcional
Tipo:	string
Valores válidos:	verdadeiro ou falso
Usado com tipos de concessão:	Implícito senha client_credentials refresh_token Também pode ser usada com a operação GenerateAuthorizationCode.

<GrantType>

<GrantType>request.queryparam.grant_type</GrantType>

Informa a política para encontrar o parâmetro de tipo de concessão que é transmitido em uma solicitação. De acordo com a especificação OAuth 2.0, o tipo de concessão precisa ser fornecido com solicitações de tokens de acesso e códigos de autorização. A variável pode ser um cabeçalho, um parâmetro de consulta ou um parâmetro de formulário (padrão).

Por exemplo, request.queryparam.grant_type indica que a senha precisa estar presente como um parâmetro de consulta, como, por exemplo, ?grant_type=password. Para exigir o tipo de concessão em um cabeçalho HTTP, por exemplo, defina esse valor como request.header.grant_type. Consulte também Receber tokens do OAuth 2.0.

Padrão:	request.formparam.grant_type (um x-www-form-urlencoded e especificado no corpo da solicitação)
Presença:	Opcional
Tipo:	string
Valores válidos:	Uma variável, conforme explicado acima.
Usado com tipos de concessão:	authorization_code senha Implícito client_credentials refresh_token

Elemento <Operation>

<Operation>GenerateAuthorizationCode</Operation>

A operação do OAuth 2.0 executada pela política.

Padrão:	Se <Operation> não for especificado, a Apigee analisará a lista de <SupportedGrantTypes>. Somente as operações nesses tipos de concessão serão bem-sucedidas. Em outras palavras, você pode omitir <Operation> se especificar um <GrantType> na lista <SupportedGrantTypes>. Se <Operation> e <SupportedGrantTypes> não forem especificados, o tipo de concessão padrão será authorization_code. Ou seja, as solicitações de tipo de concessão de autorização_codificarão, mas todas as outras falharão.
Presença:	Opcional
Tipo:	String
Valores válidos:	GenerateAccessToken: gera um token de acesso. Consulte também Receber tokens do OAuth 2.0. GenerateAccessTokenImplicitGrant: gera um token de acesso para o tipo de concessão implícita. Consulte também Receber tokens do OAuth 2.0. GenerateAuthorizationCode: gera um código de autenticação. Usado com o tipo de concessão de código de autorização. Consulte também Receber tokens do OAuth 2.0. RefreshAccessToken: troca um token de atualização por um novo token accesso. Consulte também Receber tokens do OAuth 2.0. VerifyAccessToken: verifica se um token de acesso enviado em uma solicitação é válido. Consulte a amostra VerifyAccessToken acima e Como verificar tokens de acesso. InvalidateToken: revoga um token de acesso. Depois que um token for revogado, os clientes não poderão usá-lo para chamar uma API protegida. Consulte também Como aprovar e revogar tokens de acesso. Aviso: os tokens OAuth são armazenados em cache por três minutos (180 segundos). Portanto, um token revogado ainda pode ter sucesso por até três minutos, até que o limite de cache expire. ValidateToken: restabelece ou "aprova" um token de acesso que foi revogado anteriormente. Consulte também Como aprovar e revogar tokens de acesso. Operações adicionais de token de acesso JWT Se você preferir usar tokens de acesso JWT em vez de tokens de string opacos, as operações a seguir também estarão disponíveis para gerar e validar tokens JWT. Para mais detalhes, consulte Como usar operações de token OAuth do JWT: GenerateJWTAccessToken: gera um token de acesso com um JWT assinado. Consulte Como gerar um token de acesso JWT. GenerateJWTAccessTokenImplicitGrant: gera um token de acesso com um JWT assinado para o tipo de concessão implícito. Consulte Como gerar um token de acesso JWT. VerifyJWTAccessToken: verifica um token de acesso JWT assinado. Consulte também Como verificar um token de acesso JWT. RefreshJWTAccessToken: troca um token de atualização por um novo token accesso. Consulte também Como atualizar um token de acesso JWT.

Elemento <PassWord>

<PassWord>request.queryparam.password</PassWord>

Este elemento é usado apenas com o tipo de concessão de senha. Com o tipo de concessão de senha, as credenciais de usuário (senha e nome de usuário) precisam ser disponibilizadas à política de OAuthV2. Os elementos <PassWord> e <UserName> são usados para especificar variáveis em que a Apigee pode encontrar esses valores. Se esses elementos não forem especificados, a política espera encontrar os valores (por padrão) nos parâmetros do formulário chamados username e password. Se os valores não forem encontrados, a política emitirá um erro. É possível usar os elementos <PassWord> e <UserName> para referir-se a qualquer variável de fluxo que contenha as credenciais.

Por exemplo, é possível transmitir a senha em uma solicitação de token usando um parâmetro de consulta e definir o elemento da seguinte maneira: <PassWord>request.queryparam.password</PassWord>. Para exigir a senha em um cabeçalho HTTP, defina esse valor para request.header.password.

A política OAuthV2 não faz mais nada com esses valores de credenciais; A Apigee está apenas verificando se eles estão presentes. Cabe ao desenvolvedor da API recuperar a solicitação de valores e enviá-los para um provedor de identidade antes da execução da política de geração de tokens.

Consulte também Receber tokens do OAuth 2.0.

Padrão:	request.formparam.password (um x-www-form-urlencoded e especificado no corpo da solicitação)
Presença:	Opcional
Tipo:	String
Valores válidos:	Qualquer variável de fluxo disponível para a política no ambiente da execução.
Usado com tipos de concessão:	senha

<PrivateKey>/<Value>

<PrivateKey>
  <Value ref="variable-name-here"/>
</PrivateKey>

Fornece a chave privada usada para verificar ou assinar tokens de acesso formatados em JWT com um algoritmo RSA. Use o atributo ref para passar a chave em uma variável de fluxo. Use somente quando o valor do elemento Algorithm for RS256, RS384 ou RS512. Para mais informações, consulte Como usar operações de token OAuth do JWT.

Observação: para proteger os secrets, é recomendável armazenar a chave em um conjunto de propriedades com escopo no ambiente ou um mapa de chave-valor com escopo no ambiente (KVM, na sigla em inglês). Consulte também Acessar valores de conjuntos de propriedades e Usar mapas de chave-valor.

Padrão	N/A
Presence	Obrigatório quando o valor do elemento Algorithm é um dos HS256, HS384 ou HS512.
Tipo	String
Valores válidos	Uma variável de fluxo que contém uma string que representa um valor de chave privada RSA codificado em PEM.

<PublicKey>/<Value>

<PublicKey>
   <Value ref="variable-name-here"/>
</PublicKey>

Especifica a chave pública ou o certificado público usado para verificar a assinatura em um token de acesso no formato JWT assinado com um algoritmo RSA. Use o atributo ref para passar a chave/cert em uma variável de fluxo. Use somente quando o valor do elemento Algorithm for RS256, RS384 ou RS512.

Padrão	N/A
Presence	Para verificar um JWT assinado com um algoritmo RSA, você precisa usar os elementos de Certificado, JWK ou Valor.
Tipo	String
Valores válidos	Uma variável de fluxo ou string.

Elemento <RedirectUri>

<RedirectUri>request.queryparam.redirect_uri</RedirectUri>

Específica onde a Apigee deve procurar o parâmetro redirect_uri na solicitação.

Sobre URIs de redirecionamento

Os URIs de redirecionamento são usados com os códigos de autorização e os tipos de concessão implícitos. O URI de redirecionamento informa ao servidor de autorização (Apigee) para onde enviar um código de autorização (para o tipo de concessão de código de autenticação) ou token de acesso (para o tipo de concessão implícita). É importante entender quando esse parâmetro é obrigatório, quando ele é opcional e como ele é usado:

• (obrigatório) Se um URL de callback for registrado no app de desenvolvedor associado às chaves de cliente da solicitação e se redirect_uri estiver presente na solicitação, os dois precisarão corresponder exatamente. Se não corresponderem, um erro será retornado. Para informações sobre como registrar aplicativos para desenvolvedores no Apigee e especificar um URL de retorno de chamada, consulte Registrar aplicativos e gerenciar chaves de API.

  Observação: para garantir que a Apigee verifique se há uma correspondência exata entre "URL de callback" e "redirect_uri" (em vez de uma correspondência direta), defina a seguinte propriedade em sua organização: features.isStrictOAuthUriValidation = true. O padrão é falso (correspondências futuras).

  Entre em contato com o Google Cloud Customer Care para ativar a propriedade.

• (opcional) Se um URL de uma chamada de retorno for registrado e o redirect_uri estiver ausente da solicitação, a Apigee redirecionará para o URL de callback registrado.
• (obrigatório) Se um URL de chamada de retorno não estiver registrado, o redirect_uri será necessário. Nesse caso, a Apigee aceitará qualquer URL. Este caso pode apresentar um problema de segurança, e só deve ser usado com aplicativos clientes confiáveis. Se os aplicativos clientes não forem confiáveis, a prática recomendada é sempre exigir o registro de um URL de retorno de chamada.

É possível enviar esse parâmetro em um parâmetro de consulta ou em um cabeçalho. A variável request.queryparam.redirect_uri indica que o RedirectUri precisa estar presente como um parâmetro de consulta, como, por exemplo, ?redirect_uri=login.myapp.com. Para exigir o RedirectUri em um cabeçalho HTTP, por exemplo, defina esse valor como request.header.redirect_uri. Consulte também Receber tokens do OAuth 2.0.

Padrão:	request.formparam.redirect_uri (um x-www-form-urlencoded e especificado no corpo da solicitação)
Presença:	Opcional
Tipo:	String
Valores válidos:	Qualquer variável de fluxo acessível para a política no tempo de execução
Usado com tipos de concessão:	authorization_code Implícito Também usado com a operação GenerateAuthorizationCode.

Elemento <RefreshToken>

<RefreshToken>request.queryparam.refreshtoken</RefreshToken>

Ao solicitar um token de acesso usando um token de atualização, é necessário fornecer o token de atualização na solicitação. Esse elemento permite especificar onde a Apigee precisa procurar o token de atualização. Por exemplo, ele pode ser enviado como um parâmetro de consulta, um cabeçalho HTTP ou um parâmetro de formulário (o padrão).

A variável request.queryparam.refreshtoken indica que o token de atualização precisa estar presente como um parâmetro de consulta, como, por exemplo, ?refresh_token=login.myapp.com. Para exigir ou atualizar um cabeçalho HTTP, por exemplo, defina esse valor como request.header.refresh_token. Consulte também Receber tokens do OAuth 2.0.

Padrão:	request.formparam.refresh_token (um x-www-form-urlencoded e especificado no corpo da solicitação)
Presença:	Opcional
Tipo:	String
Valores válidos:	Qualquer variável de fluxo acessível para a política no tempo de execução
Usado com tipos de concessão:	refresh_token

Elemento <RefreshTokenExpiresIn>

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

Aplica o tempo de expiração dos tokens de atualização em milissegundos. O valor do tempo de expiração é um valor gerado pelo sistema mais o valor de <RefreshTokenExpiresIn>. Se <RefreshTokenExpiresIn> for definido como -1, o token de atualização expirará de acordo com a expiração máxima do token de atualização OAuth. Se <RefreshTokenExpiresIn> não for especificado, o sistema aplicará o valor padrão.

O tempo de expiração também pode ser definido no tempo de execução usando um valor padrão codificado ou referir-se a uma variável de fluxo. Por exemplo, você pode armazenar um valor de expiração de token em um mapa de chave-valor, recuperá-lo, atribuí-lo a uma variável e referenciá-lo na política. Por exemplo, kvm.oauth.expires_in.

A estrofe a seguir especifica também uma variável de fluxo e um valor padrão. Observe que o valor da variável de fluxo tem precedência sobre o valor padrão especificado.

<RefreshTokenExpiresIn ref="kvm.oauth.expires_in">
    86400000 <!--value in milliseconds-->
</RefreshTokenExpiresIn>

Padrão:	2592000000 ms (30 dias) (início da vigência: 31 de maio de 2023)
Presença:	Opcional
Tipo:	Número inteiro
Valores válidos:	Qualquer número inteiro positivo e não zero. Especifica o tempo de expiração em milissegundos. -1 expirará de acordo com a expiração máxima do token de atualização OAuth. Observação: especificar qualquer outro número inteiro negativo ou zero causa um erro de implantação.
Usado com tipos de concessão:	authorization_code senha refresh_token

Observação: se o RefreshTokenExpiresIn estiver definido como -1, você verá o seguinte valor de expiração no token gerado: "refresh_token_expires_in" : "0".

Elemento <ResponseType>

<ResponseType>request.queryparam.response_type</ResponseType>

Esse elemento informa à Apigee qual tipo de concessão o aplicativo cliente está solicitando. Ela é usada apenas com o código de autorização e fluxos de tipo de concessão implícito.

Por padrão, a Apigee procura o valor de tipo de resposta em um parâmetro de consulta response_type. Se você quiser modificar esse comportamento padrão, use o elemento <ResponseType> para configurar uma variável de fluxo contendo o valor do tipo de resposta. Por exemplo, se você definir esse elemento como request.header.response_type, o Apigee procurará o tipo de resposta a ser passado no cabeçalho da solicitação. Consulte também Receber tokens do OAuth 2.0.

Padrão:	request.formparam.response_type (a x-www-form-urlencoded and specified in the request body)
Presença:	Opcional. Use este elemento se quiser modificar o comportamento padrão.
Tipo:	String
Valores válidos:	code (para o tipo de concessão de código de autorização) ou token (para o tipo de concessão implícito)
Usado com tipos de concessão:	Implícito Também usado com a operação GenerateAuthorizationCode.

Elemento <ReuseRefreshToken>

<ReuseRefreshToken>true</ReuseRefreshToken>

Quando definido como true, o token de atualização existente é reutilizado até que ele expire. Se for false, um novo token de atualização será emitido pela Apigee quando um token de atualização válido for apresentado.

Padrão:	false
Presença:	opcional
Tipo:	boolean
Valores válidos:	true ou false
Usado com tipo de concessão:	refresh_token

Elemento <RFCCompliantRequestResponse>

<RFCCompliantRequestResponse>[true | false]</RFCCompliantRequestResponse>

Quando true, a política está em conformidade com os padrões RFC6749 e ativa os seguintes comportamentos compatíveis:

• Respostas de erro e sem erros incluirão o campo de cabeçalho de resposta HTTP Cache-Control para obedecer ao RFC2616 (protocolo de transferência de hipertexto -- HTTP/1.1), com um valor de no-store em qualquer resposta que contenha tokens, credenciais ou outras informações sensíveis, bem como o campo de cabeçalho de resposta Pragma com um valor de no-cache.
• A propriedade expires_in estará em formato alfanumérico. Para consistência, o refresh_token_expires_in também será alfanumérico.
• As respostas OAuthV2 para geração de tokens incluirão o campo de cabeçalho Bearer compatível com RFC em vez de BearerToken.
• As mensagens de erro em payloads de resposta estarão no formato: {"error" : "xxx", "error_description" :"yyy"} para erros de token de atualização.

Observação: o RFC permite que os parâmetros não mencionados na especificação estejam na resposta do token. Portanto, não os removeremos.

Padrão:	false: por padrão, a política permite certos comportamentos não compatíveis com o RFC. Veja mais detalhes em Comportamento não compatível com o RFC. Defina esse elemento como true para ativar a conformidade com o RFC.
Presença:	Opcional
Tipo:	Booleano
Valores válidos:	true ou false
Usado com tipos de concessão:	Tudo

<SecretKey>/<Value>

<SecretKey>
  <Value ref="your-variable-name"/>
</SecretKey>

Fornece a chave secreta usada para verificar ou assinar tokens de acesso formatados em JWT com um algoritmo HMAC. Use somente quando o algoritmo for um de HS256/HS384/HS512. Use o atributo ref para passar a chave em uma variável de fluxo. Para mais informações, consulte Como usar operações de token OAuth do JWT.

A Apigee aplica uma força mínima fundamental aos algoritmos HS256/HS384/HS512. O comprimento mínimo de chave para HS256 é 32 bytes, para HS384 é 48 bytes. Para HS512, 64 bytes. O uso de uma chave de força mais baixa causa um erro de tempo de execução.

Observação: para proteger os secrets, é recomendável armazenar a chave em um conjunto de propriedades com escopo no ambiente ou um mapa de chave-valor com escopo no ambiente (KVM, na sigla em inglês). Consulte também Acessar valores de conjuntos de propriedades e Usar mapas de chave-valor.

Padrão	N/A
Presence	Obrigatório para algoritmos HMAC.
Tipo	String
Valores válidos	Uma variável de fluxo

Elemento <Scope>

<Scope>request.queryparam.scope</Scope>

Se esse elemento estiver presente em uma das políticas GenerateAccessToken ou GenerateAuthorizationCode, ele será usado para especificar os escopos que serão concedidos ao token ou código. Normalmente, esses valores são transmitidos à política na solicitação de um app cliente. Você pode configurar o elemento para ter uma variável de fluxo, dando a opção de escolher como os escopos são passados em uma solicitação. No exemplo a seguir, request.queryparam.scope indica que o escopo deve estar presente como um parâmetro de consulta, por exemplo, ?scope=READ. Para exigir o escopo em um cabeçalho HTTP, por exemplo, defina esse valor como request.header.scope.

Se esse elemento aparecer em uma política "VerifyAccessToken", ele será usado para especificar quais escopos a política precisa aplicar. Nesse tipo de política, o valor precisa ser um nome de escopo "codificado". Não é possível usar variáveis. Exemplo:

<Scope>A B</Scope>

Consulte também Como trabalhar com escopos do OAuth2 e Receber tokens do OAuth 2.0.

Padrão:	Sem escopo
Presença:	Opcional
Tipo:	String
Valores válidos:	Se usada com políticas Generate*, uma variável de fluxo. Se usadA com VerifyAccessToken, uma lista separada por espaço de nomes de escopo (strings).
Usado com tipos de concessão:	authorization_code Implícito senha client_credentials Também pode ser usado com as operações GenerateAuthorizationCode e VerifyAccessToken.

Elemento <State>

<State>request.queryparam.state</State>

Nos casos em que o app cliente precisa enviar as informações de estado ao servidor de autorização, esse elemento permite especificar onde a Apigee deve procurar os valores de estado. Por exemplo, ele pode ser enviado como um parâmetro de consulta ou em um cabeçalho HTTP. O valor do estado normalmente é usado como uma medida de segurança para evitar ataques CSRF.

Por exemplo, request.queryparam.state indica que o estado deve estar presente como um parâmetro de consulta, como, por exemplo, ?state=HjoiuKJH32. Para exigir o estado em um cabeçalho HTTP, por exemplo, defina esse valor como request.header.state. Consulte também Receber tokens do OAuth 2.0.

Padrão:	Sem estado
Presença:	Opcional
Tipo:	String
Valores válidos:	Qualquer variável de fluxo acessível para a política no tempo de execução
Usado com tipos de concessão:	Tudo Também pode ser usada com a operação GenerateAuthorizationCode

Elemento <StoreToken>

 <StoreToken>true</StoreToken>

Defina esse elemento como true quando o elemento <ExternalAuthorization> for true. O elemento <StoreToken> instrui a Apigee a armazenar o token de acesso externo. Caso contrário, não será mantida.

Padrão:	false
Presença:	Opcional
Tipo:	Booleano
Valores válidos:	verdadeiro ou falso
Usado com tipos de concessão:	authorization_code senha client_credentials

Elemento <SupportedGrantTypes>/<GrantType>

<SupportedGrantTypes>
    <GrantType>authorization_code</GrantType>
    <GrantType>client_credentials</GrantType>
    <GrantType>implicit</GrantType>
    <GrantType>password</GrantType>
</SupportedGrantTypes>

Especifica os tipos de concessão compatíveis com um endpoint de token OAuth na Apigee. Um endpoint pode aceitar vários tipos de concessão, ou seja, um único endpoint pode ser configurado para distribuir tokens de acesso para vários tipos de concessão. Para mais informações sobre endpoints, consulte Noções básicas sobre endpoints do OAuth. O tipo de concessão é transmitido em solicitações de token em um parâmetro grant_type.

Se nenhum tipo de concessão compatível for especificado, os únicos tipos de concessão permitidos serão authorization_code e implicit. Veja também o elemento <GrantType>, que é um elemento de nível superior usado para especificar onde a Apigee deve procurar o parâmetro grant_type transmitido em um cliente. solicitação. A Apigee garantirá que o valor do parâmetro grant_type corresponda a um dos tipos de concessão compatíveis.

Padrão:	authorization _code e implícito
Presença:	Obrigatório
Tipo:	String
Valores válidos:	client_credentials authorization_code senha Implícito

Elemento <Tokens>/<Token>

Usado com as operações ValidateToken e InvalidateToken. Consulte também Como aprovar e revogar tokens de acesso. O elemento <Token> identifica a variável do fluxo que define a origem do token a ser revogado. Se os desenvolvedores precisarem enviar tokens de acesso como parâmetros de consulta chamados access_token, por exemplo, use request.queryparam.access_token.

Elemento <UserName>

<UserName>request.queryparam.user_name</UserName>

Este elemento é usado apenas com o tipo de concessão de senha. Com o tipo de concessão de senha, as credenciais de usuário (senha e nome de usuário) precisam ser disponibilizadas à política de OAuthV2. Os elementos <PassWord> e <UserName> são usados para especificar variáveis em que a Apigee pode encontrar esses valores. Se esses elementos não forem especificados, a política espera encontrar os valores (por padrão) nos parâmetros do formulário chamados username e password. Se os valores não forem encontrados, a política emitirá um erro. É possível usar os elementos <PassWord> e <UserName> para referir-se a qualquer variável de fluxo que contenha as credenciais.

Por exemplo, você pode passar o nome de usuário em um parâmetro de consulta e definir o elemento <UserName> como este: <UserName>request.queryparam.username</UserName>. Para exigir o nome de usuário em um cabeçalho HTTP, defina esse valor como request.header.username.

A política OAuthV2 não faz mais nada com esses valores de credenciais; A Apigee está apenas verificando se eles estão presentes. Cabe ao desenvolvedor da API recuperar a solicitação de valores e enviá-los para um provedor de identidade antes da execução da política de geração de tokens.

Consulte também Receber tokens do OAuth 2.0.

Padrão:	request.formparam.username (um x-www-form-urlencoded e especificado no corpo da solicitação)
Presença:	Opcional
Tipo:	String
Valores válidos:	Qualquer configuração de variável.
Usado com tipos de concessão:	senha

Como verificar tokens de acesso

Quando um endpoint de token é configurado para um proxy de API, uma política OAuthV2 correspondente que especifica a operação VerifyAccessToken é anexada ao fluxo que expõe o recurso protegido.

Por exemplo, para garantir que todas as solicitações para uma API sejam autorizadas, a seguinte política impõe a verificação de token de acesso:

<OAuthV2 name="VerifyOAuthAccessToken">
  <Operation>VerifyAccessToken</Operation>
</OAuthV2>

A política está anexada ao recurso de API a ser protegido. Para garantir que todas as solicitações a uma API sejam verificadas, anexe a política ao PreFlow da solicitação ProxyEndpoint da seguinte maneira:

<PreFlow>
  <Request>
    <Step><Name>VerifyOAuthAccessToken</Name></Step>
  </Request>
</PreFlow>

Os seguintes elementos opcionais podem ser usados para substituir as definições padrão da operação VerifyAccessToken.

Nome	Descrição
Escopo	Uma lista de escopos delimitada por espaço. A verificação será bem-sucedida se pelo menos um dos escopos listados estiver presente no token de acesso. Por exemplo, a política a seguir verificará o token de acesso para garantir que ela contenha pelo menos um dos escopos listados. Se READ ou WRITE estiver presente, a verificação será bem-sucedida. <OAuthV2 name="ValidateOauthScopePolicy"> <Operation>VerifyAccessToken</Operation> <Scope>READ WRITE</Scope> </OAuthV2>
AccessToken	A variável onde se espera que o token de acesso esteja localizado. Por exemplo, request.queryparam.accesstoken. Por padrão, o token de acesso será apresentado pelo aplicativo no cabeçalho HTTP de autorização, de acordo com a especificação do OAuth 2.0. Use essa configuração se espera que o token de acesso seja apresentado em um local não padrão, como um parâmetro de consulta ou um cabeçalho HTTP com um nome diferente de Authorization.

Consulte também Como verificar tokens de acesso e Receber tokens do OAuth 2.0.

Como especificar locais de variáveis de solicitação

Para cada tipo de concessão, a política faz suposições sobre o local ou as informações necessárias em mensagens de solicitação. Essas suposições são baseadas na especificação do OAuth 2.0. Se os seus apps precisarem se desviar da especificação OAuth 2.0, especifique os locais esperados para cada parâmetro. Por exemplo, ao manipular um código de autorização, é possível especificar o local do código de autorização, o ID do cliente, o URI de redirecionamento e o escopo. Eles podem ser especificados como cabeçalhos HTTP, parâmetros de consulta ou parâmetros de formulário.

No exemplo abaixo, demonstramos como você pode especificar a localização dos parâmetros obrigatórios do código de autorização como cabeçalhos HTTP:

  ...
  <GrantType>request.header.grant_type</GrantType>
  <Code>request.header.code</Code>
  <ClientId>request.header.client_id</ClientId>
  <RedirectUri>request.header.redirect_uri</RedirectUri>
  <Scope>request.header.scope</Scope>
  ...

Ou, se necessário, para oferecer suporte à sua base de aplicativos cliente, você pode misturar e corresponder cabeçalhos e parâmetros de consulta:

  ...
  <GrantType>request.header.grant_type</GrantType>
  <Code>request.header.code</Code>
  <ClientId>request.queryparam.client_id</ClientId>
  <RedirectUri>request.queryparam.redirect_uri</RedirectUri>
  <Scope>request.queryparam.scope</Scope>
  ...

Só é possível configurar um local por parâmetro.

Variáveis de fluxo

As variáveis de fluxo definidas nesta tabela são preenchidas quando as respectivas políticas de OAuth são executadas e, portanto, estão disponíveis para outras políticas ou aplicativos em execução no fluxo de proxy da API.

Operação VerifyAccessToken

Quando a operação VerifyAccessToken é executada, um grande número de variáveis de fluxo é preenchido no contexto de execução do proxy. Essas variáveis dão propriedades relacionadas ao token de acesso, ao app do desenvolvedor e ao desenvolvedor. Você pode usar uma política do AssignMessage ou JavaScript, por exemplo, para ler qualquer uma dessas variáveis e usá-las conforme necessário mais tarde no fluxo. Essas variáveis também podem ser úteis para fins de depuração.

Observação: as variações de produtos da API serão preenchidas automaticamente se os produtos de API estiverem configurados com ambiente, proxies e recursos de API válidos, derivados do proxy.pathsuffix . Não é necessário definir explicitamente a variável flow.resource.name.

Quando os produtos de API não estão configurados com ambientes e proxies de API válidos, flow.resource.name precisa ser definido explicitamente para preencher as variações do produto de API no fluxo. Para detalhes sobre a configuração do produto, consulte Como gerenciar produtos de API.

Variáveis específicas de token

Variáveis	Descrição
organization_name	O nome da organização em que o proxy está sendo executado.
developer.id	O ID do desenvolvedor ou AppGroup associado ao app cliente registrado.
developer.app.name	O nome do desenvolvedor ou app AppGroup associado ao app cliente registrado.
client_id	O ID do cliente do aplicativo cliente registrado.
grant_type	O tipo de concessão associado à solicitação. Incompatível com a operação VerifyJWTAccessToken.
token_type	O tipo de token associado à solicitação.
access_token	O token de acesso que está sendo verificado.
accesstoken.{custom_attribute}	Um atributo personalizado nomeado no token de acesso.
issued_at	A data em que o token de acesso foi emitido, expresso no horário de era Unix em milissegundos.
expires_in	O prazo de validade do token de acesso. Expresso em segundos. Embora o elemento ExpiresIn defina a validade em milissegundos, nas variáveis de fluxo e resposta do token, o valor é expressado em segundos.
status	O status do token de acesso (por exemplo, aprovado ou revogado).
scope	O escopo (se houver) associado ao token de acesso.
apiproduct.<custom_attribute_name>	Um atributo personalizado nomeado do produto da API associado ao aplicativo cliente registrado.
apiproduct.name	O nome do produto da API associado ao aplicativo cliente registrado.
revoke_reason	(Somente híbridos da Apigee) Indica por que o token de acesso foi revogado. Incompatível com a operação VerifyJWTAccessToken. O valor pode ser REVOKED_BY_APP, REVOKED_BY_ENDUSER, REVOKED_BY_APP_ENDUSER, ou TOKEN_REVOKED.

Variáveis específicas do aplicativo

Essas variáveis estão relacionadas ao app do desenvolvedor associado ao token.

Variáveis	Descrição
app.name
app.id
app.accessType
app.callbackUrl
app.status	aprovado ou revogado
app.scopes
app.appFamily
app.apiproducts
app.appParentStatus
app.appType	Por exemplo: desenvolvedor
app.appParentId
app.created_by
app.created_at
app.last_modified_at
app.last_modified_by
app.{custom_attributes}	Um atributo personalizado nomeado do app cliente registrado.

Variáveis específicas de AppGroup

As variáveis de fluxo a seguir, que contêm informações sobre o AppGroup do token, são preenchidas pela política. Esses atributos do AppGroup são preenchidos somente se verifyapikey.{policy_name}.app.appType for "AppGroup".

Observação: se você migrar do Apigee Edge, as variáveis de fluxo da empresa ficarão automaticamente disponíveis no atributo AppGroup correspondente após a migração. Nenhuma alteração é necessária nos pacotes durante a migração.

Variáveis	Descrição
appgroup.displayName	O nome de exibição do AppGroup.
appgroup.name	Nome do AppGroup.
appgroup.id	O ID do AppGroup. Observação: esse ID é gerado internamente pela Apigee e não há garantias de que ele permanecerá o mesmo ao longo do tempo. Não use a variável appgroup.id para qualquer uma das finalidades a seguir: Identificador de cota Chaves KVM Identificadores enviados para os destinos a serem usados na lógica de negócios de back-end
appOwnerStatus	É o status do proprietário do app: "ativo", "inativo" ou "login_lock".
created_at	O carimbo de data/hora da criação do AppGroup.
created_by	O endereço de e-mail do desenvolvedor que criou o AppGroup.
last_modified_at	O carimbo de data/hora em que o AppGroup foi modificado pela última vez.
last_modified_by	O endereço de e-mail do desenvolvedor que modificou o AppGroup pela última vez.
{appgroup_custom_attributes}	Qualquer atributo personalizado do AppGroup. Especifique o nome do atributo personalizado.

Variáveis específicas de desenvolvedor

Se app.appType for "Desenvolvedor", os atributos do desenvolvedor serão preenchidos.

Variáveis	Descrição
Variáveis específicas de desenvolvedor
developer.id
developer.userName
developer.firstName
developer.lastName
developer.email
developer.status	ativo ou inativo
developer.apps	Observação: o acesso a essa variável resulta em alta latência quando o número de apps for maior que 10.
developer.created_by
developer.created_at
developer.last_modified_at
developer.last_modified_by
developer.{custom_attributes}	Um atributo personalizado nomeado do desenvolvedor.

Operação GenerateAuthorizationCode

Essas variáveis são definidas quando a operação GenerateAuthorizationCode é executada com êxito:

Prefixo: oauthv2authcode.{policy_name}.{variable_name}

Exemplo: oauthv2authcode.GenerateCodePolicy.code

Variável	Descrição
code	O código de autorização gerado quando a política é executada.
redirect_uri	O URI de redirecionamento associado ao aplicativo cliente registrado.
scope	O escopo opcional do OAuth transmitido na solicitação do cliente.
client_id	ID do cliente passado na solicitação do cliente

Operações GenerateAccessToken e RefreshAccessToken operations

Essas variáveis são definidas quando as operações GenerateAccessToken e RefreshAccessToken são executadas com êxito. As variáveis de token de atualização não se aplicam ao fluxo de tipo de credencial do cliente.

Prefixo: oauthv2accesstoken.{policy_name}.{variable_name}

Exemplo: oauthv2accesstoken.GenerateTokenPolicy.access_token

Nome da variável	Descrição
access_token	O token de acesso gerado.
client_id	O ID do cliente do aplicativo de desenvolvedor associado a este token.
expires_in	O valor de expiração do token. Consulte o elemento <ExpiresIn> para detalhes. Na resposta, expires_in é expresso em segundos.
scope	Lista dos escopos disponíveis configurados para o token. Consulte Como trabalhar com escopos do OAuth2.
status	approved ou revoked.
token_type	Está definida como BearerToken.
developer.email	O endereço de e-mail do desenvolvedor registrado que é proprietário do app de desenvolvedor associado ao token.
organization_name	A organização em que o proxy é executado.
api_product_list	Uma lista dos produtos associados ao aplicativo de desenvolvedor correspondente do token.
refresh_count
refresh_token	O token de atualização gerado. Observe que os tokens de atualização não são gerados para o tipo de concessão de credenciais do cliente.
refresh_token_expires_in	A vida útil do token de atualização, em segundos.
refresh_token_issued_at	Esse valor de tempo é a representação de string da quantidade de carimbo de data/hora correspondente de 32 bits. Por exemplo, "Quarta-feira, 21 de agosto de 2013 19:16:47 UTC" corresponde ao valor de carimbo de data/hora 1377112607413.
refresh_token_status	approved ou revoked.

GenerateAccessTokenImplicitGrant

Essas variáveis são definidas quando a operação GenerateAccessTokenImplicit é executada com êxito para o fluxo de tipo de concessão implícita.

Prefixo: oauthv2accesstoken.{policy_name}.{variable_name}

Exemplo: oauthv2accesstoken.RefreshTokenPolicy.access_token

Variável	Descrição
oauthv2accesstoken.access_token	O token de acesso gerado quando a política é executada.
oauthv2accesstoken.{policy_name}.expires_in	O valor de expiração do token, em segundos. Consulte o elemento <ExpiresIn> para detalhes.

Referência de erros

This section describes the fault codes and error messages that are returned and fault variables that are set by Apigee when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Fault code	HTTP status	Cause	Thrown by operations
steps.oauth.v2.access_token_expired	401	The access token is expired.	VerifyAccessToken InvalidateToken
steps.oauth.v2.access_token_not_approved	401	The access token was revoked.	VerifyAccessToken
steps.oauth.v2.apiresource_doesnot_exist	401	The requested resource does not exist any of the API products associated with the access token.	VerifyAccessToken
steps.oauth.v2.FailedToResolveAccessToken	500	The policy expected to find an access token in a variable specified in the <AccessToken> element, but the variable could not be resolved.	GenerateAccessToken
steps.oauth.v2.FailedToResolveAuthorizationCode	500	The policy expected to find an authorization code in a variable specified in the <Code> element, but the variable could not be resolved.	GenerateAuthorizationCode
steps.oauth.v2.FailedToResolveClientId	500	The policy expected to find the Client ID in a variable specified in the <ClientId> element, but the variable could not be resolved.	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken
steps.oauth.v2.FailedToResolveRefreshToken	500	The policy expected to find a refresh token in a variable specified in the <RefreshToken> element, but the variable could not be resolved.	RefreshAccessToken
steps.oauth.v2.FailedToResolveToken	500	The policy expected to find a token in a variable specified in the <Tokens> element, but the variable could not be resolved.	ValidateToken InvalidateToken
steps.oauth.v2.InsufficientScope	403	The access token presented in the request has a scope that does not match the scope specified in the verify access token policy. To learn about scope, see Working with OAuth2 scopes.	VerifyAccessToken
steps.oauth.v2.invalid_access_token	401	The access token sent from the client is invalid.	VerifyAccessToken
steps.oauth.v2.invalid_client	401	This error name is returned when the <GenerateResponse> property of the policy is set to true and the client ID sent in the request is invalid. Check to be sure you are using the correct client key and secret values for the Developer App associated with your proxy. Typically, these values are sent as a Base64 encoded Basic Authorization header. Note: It is recommended that you change existing fault rule conditions to catch both the invalid_client and InvalidClientIdentifier names.	GenerateAccessToken RefreshAccessToken
steps.oauth.v2.invalid_request	400	This error name is used for multiple different kinds of errors, typically for missing or incorrect parameters sent in the request. If <GenerateResponse> is set to false, use fault variables (described below) to retrieve details about the error, such as the fault name and cause.	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken
steps.oauth.v2.InvalidAccessToken	401	The authorization header does not have the word Bearer, which is required. For example: Authorization: Bearer your_access_token	VerifyAccessToken
steps.oauth.v2.InvalidAPICallAsNo\ ApiProductMatchFound	401	The currently executing API proxy or operation is not in the Product associated with the access token. Tips: Be sure that the product associated with the access token is configured correctly. For example, if you use wildcards in resource paths, be sure the wildcards are being used correctly. See Managing API products for details. See also Oauth2.0 Access Token Verification throws "Invalid API call as no apiproduct match found" error for more guidance on causes for this error.	VerifyAccessToken
steps.oauth.v2.InvalidClientIdentifier	500	This error name is returned when the <GenerateResponse> property of the policy is set to false and the client ID sent in the request is invalid. Check to be sure you are using the correct client key and secret values for the Developer App associated with your proxy. Typically, these values are sent as a Base64 encoded Basic Authorization header. Note: It is recommended that you change existing fault rule conditions to catch both the invalid_client and InvalidClientIdentifier names.	GenerateAccessToken RefreshAccessToken
steps.oauth.v2.InvalidParameter	500	The policy must specify either an access token or an authorization code, but not both.	GenerateAuthorizationCode GenerateAccessTokenImplicitGrant
steps.oauth.v2.InvalidTokenType	500	The <Tokens>/<Token> element requires you to specify the token type (for example, refreshtoken). If the client passes the wrong type, this error is thrown.	ValidateToken InvalidateToken
steps.oauth.v2.MissingParameter	500	The response type is token, but no grant types are specified.	GenerateAuthorizationCode GenerateAccessTokenImplicitGrant
steps.oauth.v2.UnSupportedGrantType	500	The client specified a grant type that is unsupported by the policy (not listed in the <SupportedGrantTypes> element). Note: There is currently a bug where unsupported grant type errors are not thrown correctly. If an unsupported grant type error occurs, the proxy does not enter the Error Flow, as expected.	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken

JWT token-specific runtime errors

Runtime error codes and descriptions for JWT auth token flows depend on the OAuth2 flow context:

• If the flow context is token generation or refresh, see Error codes for JWT token generation and refresh flows below.
• For the token verification flow, see Error codes for token verification flows below.

Error codes for JWT token generation and refresh flows

For OAuth2 flows that generate or refresh JWT tokens, error responses adhere to the error responses specified in RFC6749. For details, see Section 5.2 Error Response.

Error codes for the token verification flow

The error codes listed in the following table apply to VerifyAccessToken operation only.

Fault code	HTTP status	Cause	Thrown by operations
oauth.v2.JWTSigningFailed	401	The policy was unable to sign the JWT.	GenerateJWTAccessToken
oauth.v2.InvalidValueForJWTAlgorithm	401	This occurs when the algorithm is not present in the JWT access token or when the value is not supported.	GenerateJWTAccessToken VerifyJWTAccessToken
oauth.v2.InsufficientKeyLength	401	In Generation of JWT, for a key less than the minimum size for the HS384 or HS512 algorithms	GenerateJWTAccessToken VerifyJWTAccessToken
oauth.v2.JWTAlgorithmMismatch	401	The algorithm specified in the Generate policy did not match the one expected in the Verify policy. The algorithms specified must match.	VerifyJWTAccessToken
oauth.v2.JWTDecodingFailed	401	The policy was unable to decode the JWT. The JWT is possibly corrupted.	VerifyJWTAccessToken
oauth.v2.MissingMandatoryClaimsInJWT	401	Occurs when the required claims are not present in the Jwt Access token	VerifyJWTAccessToken
oauth.v2.InvalidJWTSignature	401	This occurs when the signature of JWT access token could not be verified or when the signature is invalid.	VerifyJWTAccessToken
oauth.v2.InvalidTypeInJWTHeader	401	Occurs when the JWT's type is not at+Jwt	VerifyJWTAccessToken

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Error name	Cause
InvalidValueForExpiresIn	For the <ExpiresIn> element, valid values are positive integers and -1.
InvalidValueForRefreshTokenExpiresIn	For the <RefreshTokenExpiresIn> element, valid values are positive integers and -1.
InvalidGrantType	An invalid grant type is specified in the <SupportedGrantTypes> element. See the policy reference for a list of valid types.
ExpiresInNotApplicableForOperation	Be sure that the operations specified in the <Operations> element support expiration. For example, the VerifyToken operation does not.
RefreshTokenExpiresInNotApplicableForOperation	Be sure that the operations specified in the <Operations> element support refresh token expiration. For example, the VerifyToken operation does not.
GrantTypesNotApplicableForOperation	Be sure that the grant types specified in <SupportedGrantTypes> are supported for the specified operation.
OperationRequired	You must specify an operation in this policy using the <Operation> element. Note: If the <Operation> element is missing, the UI throws a schema validation error.
InvalidOperation	You must specify a valid operation in this policy using the <Operation> element. Note: If the <Operation> element is invalid, the UI throws a schema validation error.
TokenValueRequired	You must specify a token <Token> value in the <Tokens> element.

JWT token-specific deployment errors

These deployment errors are specific to policies that use JWT token operations.

Error name	Cause
InvalidValueForAlgorithm	The algorithm specified in the <Algorithm> element is not among the list of available algorithms or is not present.
MissingKeyConfiguration	The required <SecretKey>, <PrivateKey>, or <PublicKey> elements are missing, depending on which algorithm is used.
EmptyValueElementForKeyConfiguration	The required child element <Value> is not defined in the <PrivateKey>, <PublicKey>, or <SecretKey> elements
InvalidKeyConfiguration	The <PrivateKey> element is not used with RSA family algorithms or the <SecretKey> element is not used with HS Family algorithms.
EmptyRefAttributeForKeyconfiguration	The ref attribute of the child element <Value> of the <PrivateKey>, <PublicKey> or <SecretKey> elements is empty.
InvalidVariableNameForKey	The flow variable name specified in the ref attribute of the child element <Value> of the <PrivateKey>, <PublicKey> or <SecretKey> elements does not contain the private prefix.

Fault variables

These variables are set when this policy triggers an error at runtime.

Note: You can use these variables to create Fault Rule conditions. These variables are populated when an error occurs if <GenerateResponse> is set to false. If <GenerateResponse> is true, the policy returns a response to the client immediately if an error occurs -- the error flow is skipped and these variables are not populated. For more information, see What you need to know about policy errors.

Variables	Where	Example
fault.name="fault_name"	fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code.	fault.name = "invalid_request"
oauthV2.policy_name.failed	policy_name is the user-specified name of the policy that threw the fault.	oauthV2.GenerateAccesstoken.failed = true
oauthV2.policy_name.fault.name	policy_name is the user-specified name of the policy that threw the fault.	oauthV2.GenerateAccesstoken.fault.name = invalid_request Note: For the VerifyAccessToken operation, the fault name includes this suffix: keymanagement.service For example: keymanagement.service.invalid_access_token
oauthV2.policy_name.fault.cause	policy_name is the user-specified name of the policy that threw the fault.	oauthV2.GenerateAccesstoken.cause = Required param : grant_type

Example error response

These responses are sent back to the client if the <GenerateResponse> element is true.

Note: For error handling, the best practice is to trap the errorcode part of the error response. Do not rely on the text in the faultstring, because it could change.

If <GenerateResponse> is true, the policy returns errors in this format for operations that generate tokens and codes. For a complete list, see see OAuth HTTP error response reference.

{"ErrorCode" : "invalid_client", "Error" :"ClientId is Invalid"}

If <GenerateResponse> is true, the policy returns errors in this format for verify and validate operations. For a complete list, see see OAuth HTTP error response reference.

{  
   {  
      "fault":{  
         "faultstring":"Invalid Access Token",
         "detail":{  
            "errorcode":"keymanagement.service.invalid_access_token"
         }
      }
   }

Example fault rule

<FaultRule name="OAuthV2 Faults">
    <Step>
        <Name>AM-InvalidClientResponse</Name>
        <Condition>(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")</Condition>
    </Step>
    <Step>
        <Name>AM-InvalidTokenResponse</Name>
        <Condition>(fault.name = "invalid_access_token")</Condition>
    </Step>
    <Condition>(oauthV2.failed = true) </Condition>
</FaultRule>

Os tokens no Storage são criptografados com hash

Se você estiver usando a Apigee híbrida ou a Apigee, os tokens de acesso e os tokens de atualização do OAuthV2 serão criptografados com hash por padrão quando armazenados no banco de dados do ambiente de execução do Cassandra. O hash impede que os tokens sejam usados se o banco de dados estiver comprometido.

Como trabalhar com a configuração padrão do OAuth

Todas as organizações (até mesmo uma organização de avaliação gratuita) na Apigee são provisionadas com um endpoint de token OAuth. O endpoint é pré-configurado com políticas no proxy de API chamado oauth. É possível começar a usar o endpoint de token assim que criar uma conta na Apigee. Para detalhes, consulte Noções básicas sobre os endpoints do OAuth.

Como limpar tokens de acesso

Por padrão, os tokens OAuth2 são eliminados do sistema Apigee três dias (259.200 segundos) depois que o token de acesso e o token de atualização (se houver) tiverem expirado.

Comportamento não compatível com a RFC

Por padrão, a política OAuthV2, com a operação GenerateAccessToken, retorna uma resposta de token que contém determinadas propriedades não compatíveis com o RFC. A tabela a seguir mostra as propriedades não compatíveis retornadas pela política OAuthV2 e as propriedades compatíveis correspondentes.

Observação: se você exigir que esses elementos sejam compatíveis, defina o elemento RFCCompliantRequestResponse para true

O OAuthV2 retorna:	A propriedade em conformidade com a RFC é:
"token_type":"BearerToken"	"token_type":"Bearer"
"expires_in":"3600"	"expires_in":3600 O valor em conformidade é um número, não uma string.

Além disso, a resposta de erro de um token de atualização expirado quando grant_type = refresh_token é:

{"ErrorCode" : "invalid_request", "Error" :"Refresh Token expired"}

No entanto, a resposta compatível com RFC é:

{"error" : "invalid_grant", "error_description" :"refresh token expired"}

Temas relacionados

• Introdução ao OAuth 2.0