Como compartilhar clientes OAuth

Nesta página, explicamos como compartilhar um cliente OAuth com outro aplicativo na sua organização.

Visão geral

O compartilhamento de clientes OAuth entre projetos significa usar um único cliente OAuth personalizado para vários aplicativos protegidos pelo Identity-Aware Proxy (IAP) em vez de criar um novo cliente OAuth para cada aplicativo. Essa abordagem simplifica o gerenciamento, especialmente para organizações com muitos aplicativos.

Ao configurar o IAP, você pode usar um destes dois tipos de cliente OAuth:

  • Cliente OAuth gerenciado pelo Google: o IAP usa esse cliente automaticamente por padrão. Essa opção integrada não exige a criação manual do cliente, mas tem duas limitações principais:

    • Permite acesso apenas a usuários da sua organização (usuários internos)
    • Mostra a marca na tela de permissão em vez da marca da sua organização Google Cloud

  • Cliente OAuth personalizado: você cria e gerencia esse cliente. Essa opção:

    • Pode ser compartilhada em vários aplicativos
    • Permite a personalização da marca na tela de permissão
    • Oferece suporte ao acesso de usuários externos (fora da sua organização)

Ao criar um cliente OAuth personalizado, você tem a flexibilidade de usá-lo com um único aplicativo ou compartilhá-lo em vários aplicativos. O compartilhamento de um cliente OAuth personalizado oferece vários benefícios:

  • Reduz a sobrecarga administrativa do gerenciamento de vários clientes
  • Simplifica a ativação do IAP para membros da equipe que não devem ter acesso à página "Credenciais"
  • Facilita o acesso programático (não navegador) a aplicativos protegidos pelo IAP

Para informações sobre como criar clientes OAuth, consulte Criar clientes OAuth para IAP. Para detalhes sobre clientes OAuth gerenciados pelo Google, consulte Personalizar uma configuração do OAuth para ativar o IAP.

Antes de começar

Crie um novo cliente OAuth seguindo as etapas em Criação de clientes OAuth ou use um cliente OAuth atual.

Acesso programático

Configure clientes OAuth para acesso programático para permitir que aplicativos que não são navegadores façam a autenticação com seus recursos protegidos pelo IAP. Isso permite que scripts, jobs automatizados e serviços de back-end acessem com segurança seus aplicativos protegidos sem o login interativo do usuário.

É possível aplicar essas configurações de autenticação em qualquer nível da hierarquia de recursos: organização, pasta, ou projeto.

Para etapas de implementação, consulte o guia de autenticação programática e a documentação de gerenciamento de configurações do IAP.

gcloud

  1. Prepare um arquivo de configurações com seus IDs do cliente OAuth:

    cat << EOF > SETTINGS_FILENAME
  access_settings:
    oauth_settings:
      programmatic_clients: [clientId1, clientId2, ..]
EOF

  2. Aplique as configurações usando o gcloud iap settings set comando:

    gcloud iap settings set SETTINGS_FILENAME \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

    Exemplos de comandos:

    # Organization level
gcloud iap settings set SETTINGS_FILENAME --organization=ORGANIZATION

# Folder level
gcloud iap settings set SETTINGS_FILENAME --folder=FOLDER

# Project level (web resources)
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=iap_web

# App Engine service in a project
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=app-engine \
  --service=SERVICE

    Em que:

    • SETTINGS_FILENAME: o arquivo YAML que você preparou.
    • ORGANIZATION: o ID da organização
    • FOLDER: o ID da pasta
    • PROJECT: o ID do projeto
    • RESOURCE_TYPE: o tipo de recurso do IAP (app-engine, iap_web, compute, organization ou folder)
    • SERVICE: o nome do serviço (opcional para compute ou app-engine tipos de recursos)
    • VERSION: o nome da versão (não aplicável para compute, opcional para app-engine)

API

  1. Prepare um arquivo JSON de configurações:

    cat << EOF > iap_settings.json
{
  "access_settings": {
    "oauth_settings": {
      programmatic_clients: [clientId1, clientId2, ..]
    }
  }
}
EOF

  2. Encontre o nome do recurso:

    gcloud iap settings get \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

  3. Atualize as configurações usando o nome do recurso:

    curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d @iap_settings.json \
"https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.oauthSettings.programmaticClients"

    Em que:

    • ORGANIZATION: o ID da organização
    • FOLDER: o ID da pasta
    • PROJECT: o ID do projeto
    • RESOURCE_TYPE: o tipo de recurso do IAP (app-engine, iap_web, compute, organization ou folder)
    • SERVICE: o nome do serviço (opcional para compute ou app-engine tipos de recursos)
    • VERSION: o nome da versão (não aplicável para compute, opcional para app-engine)

Após a configuração, faça login no aplicativo usando um dos IDs do cliente OAuth configurados. Consulte Autenticação programática para mais detalhes.

Acesso ao navegador

Para permitir que o IAP use o ID e a chave secreta do cliente pelo Google Cloud console, siga estas instruções:

Riscos

Embora o compartilhamento de um cliente entre seus aplicativos seja conveniente, há riscos. Nesta seção, descrevemos os riscos potenciais ao compartilhar clientes e como minimizá-los.

Ponto único de falha

Usar um cliente OAuth para muitos aplicativos cria um ponto único de dependência. Se um cliente for excluído ou modificado incorretamente, todos os aplicativos que o usam serão afetados. Os clientes OAuth excluídos podem ser restaurados em até 30 dias.

Para gerenciar esse risco operacional de maneira eficaz:

Esse é principalmente um risco operacional, e não de segurança. Com controles de acesso e monitoramento adequados, os benefícios de conveniência e gerenciamento de clientes OAuth compartilhados geralmente superam essa consideração.

Vazamentos de chaves secretas do cliente

O compartilhamento de um cliente exige que você compartilhe a chave secreta do cliente com pessoas e scripts. Isso aumenta o risco de vazamento da chave secreta do cliente. O IAP não pode diferenciar entre tokens criados no aplicativo e tokens criados com uma chave secreta do cliente vazada.

Para reduzir esse risco:

  • Proteja as chaves secretas do cliente como senhas e nunca as armazene como texto simples
  • Implemente o gerenciamento seguro de credenciais usando o Secret Manager
  • Monitore o acesso aos recursos do IAP com o Cloud Audit Logging
  • Uma chave secreta do cliente vazada afeta apenas a autenticação, não a autorização para acessar recursos. Se você suspeitar que sua chave secreta foi vazada, redefina-a imediatamente.

Para acesso programático a recursos protegidos pelo IAP, considere usar a autenticação JWT da conta de serviço em vez de compartilhar chaves secretas do cliente OAuth com usuários individuais. Essa abordagem oferece melhor isolamento de segurança, mantendo os benefícios de um cliente OAuth compartilhado para seus aplicativos.

Considerações sobre o escopo de permissão

Ao compartilhar clientes OAuth, todos os aplicativos usam os mesmos escopos de permissão. Para o IAP, openid e email são os únicos escopos necessários. Essa consideração por si só não é um risco significativo, mas é importante entender:

  • O OAuth é usado apenas para autenticação (verificação de identidade) no IAP; a autorização (acesso a recursos) é processada separadamente pelas políticas do IAM
  • Mesmo que as credenciais de autenticação sejam comprometidas, um invasor ainda precisaria das permissões do IAM adequadas para acessar recursos protegidos
  • Restringir o cliente apenas aos escopos openid e email necessários ajuda a limitar o possível impacto na segurança