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

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

A Apigee Edge oferece o framework do OAuth 2.0 para APIs seguras. 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 atualização implementando qualquer um os quatro tipos de concessão do OAuth2: credenciais do cliente, senha, implícito, 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 validade própria 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. O prazo de validade dos tokens de atualização também pode ser definido na política do OAuthv2.

Esse antipadrão está relacionado ao antipadrão de a definição de um prazo de validade longo para tokens OAuth.

Antipadrão

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

O exemplo a seguir de política do OAuthV2 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 foi definida.
  • O token de atualização persiste no armazenamento de dados (Cassandra) para sempre, causando dados 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 para essa 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 ter acesso com base no token correto anterior. Isso pode ter implicações na 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 obter um novo token de acesso, mas sim criar um novo token de atualização e de acesso, o token de atualização antigo permanecerá no Cassandra. Como resultado, atualize os tokens vão continuar se acumulando no Cassandra, aumentando a ocupação aumento do uso de disco e compactações mais pesadas, o que acabará causando a leitura/gravação latências no Cassandra.

Prática recomendada

Use um prazo de validade apropriado para os tokens de atualização e de acesso. Consulte prática recomendada para configurar a expiração dos tokens de acesso e atualização. Especifique uma configuração de expiração para os dois acessos e o token de atualização na política. Consulte a Documentação da política do OAuthV2 para mais detalhes sobre a configuração de políticas.

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

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

Especificar a validade padrão do token de atualização

Por padrão, se a expiração de um token de atualização não for especificada em uma configuração de política, O Edge cria um token de atualização sem expiração. Para substituir esse comportamento, o seguinte procedimento:

  1. Em um nó do processador de mensagens, edite ou crie o arquivo de substituição da configuração $APIGEE_ROOT/customer/application/message-processor.properties: Certifique-se de que este arquivo seja legível 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 alterar esse valor padrão com base nas necessidades da sua empresa.
  3. Reinicie o serviço 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 para lançar correções e melhorias que continuam a melhorar e otimizar o gerenciamento de tokens na Apigee. Na Apigee, os tokens de acesso e atualização são armazenados no Cassandra dentro do keyspace “kms”. Você deve garantir que a estratégia de compactação keyspace é definido 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 menor (como 3 dias) para garantir que as tombstones geradas devido à exclusão de tokens sejam limpos do repositório de dados com mais rapidez.

Leitura adicional