Está a ver a documentação do Apigee e do Apigee Hybrid.
Veja a documentação do
Apigee Edge.
O Apigee fornece um conjunto de ferramentas e políticas que lhe permitem implementar a autenticação baseada em tokens OAuth 2.0 para proteger as suas APIs. O OAuth2, descrito no IETF RFC 6749, é a norma aberta mais amplamente suportada para autenticação e autorização para APIs. Estabelece o token como uma credencial de formato padrão que as aplicações cliente enviam para implementações de API. A implementação da API pode validar o token para determinar se o cliente está autorizado a aceder à API.
O Apigee permite que os programadores gerem tokens de acesso e/ou atualização através da implementação de qualquer um dos quatro tipos de concessão do OAuth2: credenciais do cliente, palavra-passe, implícito e código de autorização, usando a política OAuthv2. Além disso, os programadores de APIs podem usar o Apigee para implementar autorizações personalizadas, incluindo autorizações que seguem o padrão de troca de tokens, conforme descrito no IETF RFC 8693. As aplicações cliente usam, em seguida, chaves de acesso para consumir APIs seguras. Cada token de acesso tem o seu próprio tempo de validade, que pode ser definido na política OAuthv2.
O Apigee pode, opcionalmente, gerar e devolver um token de atualização juntamente com o token de acesso com alguns dos tipos de autorização. Um cliente usa um símbolo de atualização para obter uma nova chave de acesso depois de a chave de acesso original ser revogada ou expirar. O tempo de expiração do token de atualização também pode ser definido na política OAuthv2.
Antipattern
A definição de um longo período de validade para uma chave de acesso ou uma chave de atualização na política OAuthv2 resulta num período de vulnerabilidade alargado em caso de fuga de chaves, o que representa um risco de segurança. Também pode levar a uma acumulação de tokens OAuth no armazenamento persistente, o que pode resultar numa diminuição do desempenho ao longo do tempo.
Exemplo 1
A política OAuthV2 de exemplo seguinte mostra um tempo de expiração longo de 10 dias para as chaves de acesso:
<OAuthV2 name="OAuth-GenerateAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>864000000</ExpiresIn> <!-- 10 days -->
<RefreshTokenExpiresIn>864000000</RefreshTokenExpiresIn> <!-- 10 days -->
<SupportedGrantTypes>
<GrantType>authorization_code</GrantType>
</SupportedGrantTypes>
<GenerateResponse enabled="true"/>
</OAuthV2>No exemplo acima:
- A duração da chave de acesso está definida para 10 dias.
- A duração do token de atualização também está definida como 10 dias.
Impacto
As chaves de acesso duradouras representam um risco de segurança. Em caso de fuga ou perda de tokens, um token de curta duração expira naturalmente e torna-se inútil, enquanto um token de longa duração continua a conceder acesso à API durante um período potencialmente prolongado, aumentando a janela de vulnerabilidade.
Um token de acesso deve ter um tempo de vida curto, provavelmente cerca de 30 minutos ou menos, e esse tempo de vida deve ser substancialmente inferior ao tempo de vida do token de atualização.
Exemplo 2
O exemplo de política OAuthV2 seguinte mostra um longo tempo de expiração de 200 dias para tokens de atualização:
<OAuthV2 name="OAuth-GenerateAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
<RefreshTokenExpiresIn>17280000000</RefreshTokenExpiresIn> <!-- 200 days -->
<SupportedGrantTypes>
<GrantType>authorization_code</GrantType>
</SupportedGrantTypes>
<GenerateResponse enabled="true"/>
</OAuthV2>No exemplo acima:
- A chave de acesso é definida com um tempo de expiração razoável e curto de 30 minutos.
- O token de atualização é definido com um tempo de expiração muito longo de 200 dias.
- Se o tráfego para esta API for de 10 pedidos/segundo, pode gerar até 864 000 tokens num dia.
- Os tokens de atualização expiram após 200 dias e acumulam-se no arquivo de dados durante toda a duração.
Impacto
A duração prolongada do token de atualização pode levar a uma degradação do desempenho ao longo do tempo, uma vez que se acumula um grande número de tokens no armazenamento de dados. No Apigee hybrid, a acumulação excessiva de tokens também pode contribuir para o esgotamento do espaço em disco na camada de persistência.
Prática recomendada
Use um prazo de validade para os tokens de acesso e de atualização OAuth adequado aos seus requisitos de segurança específicos, para reduzir a janela de vulnerabilidade para tokens roubados e evitar a acumulação de tokens no armazenamento de dados. Um bom ponto de partida para a duração total do token de acesso é de 30 minutos. Para a duração total do token de atualização, comece com 24 horas.
Defina o tempo de validade das chaves de atualização de forma que seja válido por um múltiplo da duração das chaves de acesso. Por exemplo, se definir 30 minutos para o token de acesso, defina o período de interação do token de atualização como 24 horas, 7 dias ou o que for adequado para a experiência do utilizador que precisa de suportar.