Antipadrão: definir um prazo de validade para os tokens OAuth

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

O Apigee Edge fornece o framework OAuth 2.0 para proteger APIs. O OAuth2 é um dos esquemas de autorização e autenticação de padrão aberto com base em tokens mais conhecidos. Ele permite que os aplicativos clientes acessem as APIs em nome dos usuários sem que eles precisem divulgar o nome de usuário e a senha.

O Apigee Edge permite que os desenvolvedores gerem tokens de acesso e/ou de atualização implementando qualquer um dos quatro tipos de concessão do OAuth2 (credenciais do cliente, senha, implícita e código de autorização) usando a política do OAuthv2. Os aplicativos clientes usam os tokens de acesso para consumir APIs seguras. Cada token de acesso tem um prazo de validade próprio, que pode ser definido na política do OAuthv2.

Os tokens de atualização podem ser emitidos junto com os tokens de acesso com alguns dos tipos de concessão. Os tokens de atualização serão usados para receber novos tokens de acesso válidos depois que o token de acesso original expirar ou ser revogado. Também é possível definir o prazo de validade dos tokens de atualização na política do OAuthv2.

Esse antipadrão está relacionado ao antipadrão de definir um prazo de expiração longo para tokens OAuth.

Antipadrão

Não definir um prazo de validade para um token de atualização na política OAuthv2 leva ao acúmulo de tokens OAuth e ao aumento do uso do espaço em disco nos nós do Cassandra.

O exemplo de política OAuthV2 a seguir mostra uma configuração ausente para <RefreshTokenExpiresIn>: 

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

No exemplo acima:

  • O token de acesso é definido com um prazo de validade razoavelmente baixo de 30 minutos.
  • A expiração do token de atualização não está definida.
  • O token de atualização persiste no armazenamento de dados (Cassandra) para sempre, causando o acúmulo de dados.
  • Um token de atualização criado sem expiração pode ser usado indefinidamente para gerar tokens de acesso.
  • Se o tráfego dessa API for de 10 solicitações por segundo, ela poderá gerar até 864.000 tokens em um dia.

Impacto

  • Se o token de atualização for criado sem expiração, haverá duas consequências principais:
    • O token de atualização pode ser usado a qualquer momento no futuro, possivelmente por anos, para receber um token de acesso. Isso pode afetar a segurança.
    • A linha no Cassandra que contém o token de atualização nunca será excluída. Isso fará com que os dados se acumulem no Cassandra.
  • Se você não usar o token de atualização para receber um novo token de acesso, mas criar um novo token de atualização e acesso, o mais antigo permanecerá no Cassandra. Como resultado, os tokens de atualização continuarão acumulando no Cassandra, aumentando ainda mais a sobrecarga, o uso de disco e as compactações mais pesadas, causando latências de leitura/gravação no Cassandra.

Prática recomendada

Use um prazo de validade adequado para os tokens de atualização e de acesso. Consulte as práticas recomendadas para definir tempos de expiração para tokens de atualização e acesso. Especifique uma configuração de expiração para o token de acesso e de atualização na política. Consulte a documentação da política do OauthV2 para mais detalhes sobre a configuração da política.

Práticas recomendadas para clientes do Edge para nuvem privada

Nesta seção, descrevemos as práticas recomendadas especificamente para clientes do Edge para nuvem privada.

Especificar uma expiração padrão do token de atualização

Por padrão, se uma expiração do token de atualização não for especificada em uma configuração de política, o Edge criará um token de atualização sem expiração. É possível modificar esse comportamento com o seguinte procedimento:

  1. Em um nó do processador de mensagens, edite ou crie o arquivo de substituição de configuração $APIGEE_ROOT/customer/application/message-processor.properties. Verifique se o arquivo pode ser lido pelo usuário de apigee.
  2. Adicione a seguinte linha ao arquivo: 
    conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
    Isso definirá a validade padrão do token de atualização, se nenhuma estiver especificada em uma política, para 1 hora. É possível alterar esse valor padrão com base nas necessidades da sua empresa.
  3. Reinicie o serviço de processador de mensagens: 
    apigee-service edge-message-processor restart
  4. Repita as etapas acima em todos os nós do processador de mensagens, um por um.

Práticas recomendadas no Cassandra

Tente fazer upgrade para a versão mais recente da Apigee disponível publicamente. A Apigee continua lançando correções e melhorias que continuam a melhorar e otimizar o gerenciamento de tokens na Apigee. Na Apigee, os tokens de acesso e de atualização são armazenados no Cassandra no keyspace "kms". A estratégia de compactação desse keyspace precisa estar definida como LeveledCompactionStrategy. Confira se os seguintes índices não estão presentes:
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_organization_name_idx#f0f0f0 e
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_status_idx

Também é possível reduzir gc_grace_seconds na tabela kms.oauth_20_access_tokens de 10 dias padrão para um valor menor (como 3 dias) para garantir que tombstones gerados devido à exclusão de tokens sejam limpados do repositório de dados mais rapidamente.

Leia mais