Como compartilhar clientes OAuth

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

Visão geral

Compartilhar 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 de 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 de clientes, mas tem duas limitações principais:

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

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

    • Podem ser compartilhados entre vários aplicativos
    • Permite a personalização da marca na tela de permissão
    • Suporta acesso para 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. Compartilhar um cliente OAuth personalizado oferece vários benefícios:

  • Reduz a sobrecarga administrativa de gerenciar vários clientes
  • Simplifica a ativação da 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 Como criar clientes OAuth para IAP. Para detalhes sobre clientes OAuth gerenciados pelo Google, consulte Personalizar uma configuração do OAuth para ativar a IAP.

Antes de começar

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

Acesso programático

Configure clientes OAuth para acesso programático e permita que aplicativos que não são de navegador se autentiquem 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 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 conferir as 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 comando gcloud iap settings set:

    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 tipos de recursos compute ou app-engine)
    • 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. Encontrar 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 tipos de recursos compute ou app-engine)
    • VERSION: o nome da versão (não aplicável para compute, opcional para app-engine)

Depois da configuração, faça login no aplicativo usando um dos IDs de cliente OAuth que você configurou. Consulte Autenticação programática para mais detalhes.

Acesso ao navegador

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

Riscos

Compartilhar um cliente entre seus aplicativos é conveniente, mas 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 único ponto de dependência. Se um cliente for excluído ou modificado incorretamente, todos os aplicativos que usam esse cliente 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, não de segurança. Com controles de acesso e monitoramento adequados, os benefícios de conveniência e gerenciamento dos clientes OAuth compartilhados geralmente superam essa consideração.

Vazamentos de chaves secretas do cliente

Compartilhar um cliente requer o compartilhamento da chave secreta dele com pessoas e scripts, o que aumenta o risco de vazamento. O IAP não consegue diferenciar entre os tokens criados a partir do seu aplicativo ou de uma chave secreta do cliente que vazou.

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 seu secret foi vazado, redefina-o 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 segredos do cliente OAuth com usuários individuais. Essa abordagem oferece um isolamento de segurança melhor, 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 IAP, openid e email são os únicos escopos obrigató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 por políticas do IAM.
  • Mesmo que as credenciais de autenticação sejam comprometidas, um invasor ainda precisaria das permissões adequadas do IAM 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.