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

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

A 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.

A Apigee Edge permite que os desenvolvedores gerem tokens de acesso e/ou de atualização implementando um dos quatro tipos de concessão do OAuth2: credenciais de cliente, senha, implícito e código de autorização - como usar a política OAuthv2. Os aplicativos clientes usam os tokens de acesso para consumir APIs seguras. Cada token de acesso tem seu próprio tempo de expiração, que pode ser definido na política 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. O tempo de expiração dos tokens de atualização também pode ser definido na política do OAuthv2 (em inglês).

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

Antipadrão

A definição de um tempo de expiração para um token de atualização na política OAuthv2 leva ao acúmulo de tokens OAuth e a um aumento no uso de 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 tempo de expiração razoavelmente baixo de 30 minutos.
  • A expiração do token de atualização não está definida.
  • O token de atualização persiste no repositório de dados (Cassandra) para sempre, causando acúmulo de dados.
  • Um token de atualização gerado sem expiração pode ser usado indefinidamente para gerar tokens de acesso.
  • Se o tráfego para essa API for de dez solicitações por segundo, ele 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 token. Isso pode ter implicações de 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 um token de acesso, o token de atualização mais antigo permanecerá no Cassandra. Como resultado, os tokens de atualização continuarão se acumulando no Cassandra, aumentando ainda mais o inchaço, o uso de disco e as compactações mais pesadas, e acabarão causando latências de leitura/gravação no Cassandra.

Prática recomendada

Use um tempo de expiração adequadamente baixo para tokens de atualização e de acesso. Consulte a prática recomendada para definir os tempos de expiração de tokens de atualização e de 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 OauthV2 para mais detalhes sobre a configuração da política.

Práticas recomendadas especificamente para clientes do Edge para nuvem privada

A seção descreve 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 substituir esse comportamento por o procedimento a seguir:

  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 esse arquivo pode ser lido pelo usuário apigee.
  2. Adicione a linha a seguir ao arquivo: 
    conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
     Isso definirá a expiração padrão do token de atualização, se nenhuma for especificada em uma política, como 1 hora. É possível mudar esse valor padrão com base nas necessidades da sua empresa.
  3. Reinicie o serviço do 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". Verifique se a estratégia de compactação desse keyspace está definida como LeveledCompactionStrategy. Verifique 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 do padrão de 10 dias para um valor menor (como 3 dias) para garantir que os marcadores de exclusão gerados devido à exclusão de tokens sejam limpos do repositório de dados mais rapidamente.

Leitura adicional