Como compartilhar clientes OAuth

Esta página explica como compartilhar um cliente OAuth com outro aplicativo na 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 cliente OAuth para cada aplicativo. Essa abordagem simplifica o gerenciamento, especialmente para organizações com muitos aplicativos.

Ao configurar o IAP, é possível usar um dos 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 da 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 do gerenciamento de 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 Criar clientes OAuth para o 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 cliente OAuth seguindo as etapas em Criação de cliente OAuth ou use um cliente OAuth já 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 da 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 de compra no app (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 relevante 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. Extraia 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 de compra no app (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 relevante 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 a IAP use seu ID do cliente e sua chave secreta pelo consoleGoogle Cloud , siga estas instruções:

Riscos

Embora seja conveniente compartilhar um cliente entre seus aplicativos, 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 compartilhar a chave secreta do cliente com pessoas e scripts. Isso aumenta o risco de vazamento da chave secreta do cliente. A IAP não consegue diferenciar entre tokens criados no seu 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 seus recursos do IAP com os Registros de auditoria do Cloud.
  • 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 chaves secretas do cliente OAuth com usuários individuais. Essa abordagem oferece melhor isolamento de segurança e mantém 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 os recursos protegidos.
  • Restringir o cliente apenas aos escopos openid e email necessários ajuda a limitar o possível impacto na segurança.