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, na sigla em inglês) 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 dos dois tipos de cliente OAuth:

  • Cliente OAuth gerenciado pelo Google: o IAP usa esse tipo automaticamente. 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 o branding Google Cloud na tela de consentimento em vez do branding da sua organização.

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

    • Pode ser compartilhado entre vários aplicativos
    • Permite a personalização da marca na tela de consentimento
    • Suporte a 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 de gerenciamento de vários clientes
  • Simplifica a ativação do IAP para membros da equipe que não podem ter acesso à página de credenciais.
  • Facilita o acesso programático (fora do navegador) a aplicativos protegidos pelo IAP

Para informações sobre como criar clientes OAuth, consulte Como criar clientes OAuth para IAP. Para saber mais sobre os 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 existente.

Acesso programático

Configure clientes OAuth para acesso programático para permitir que aplicativos que não são de navegador se autentiquem com seus recursos protegidos pelo IAP. Isso permite que scripts, trabalhos 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 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 de 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 recurso compute ou app-engine)
    • VERSION: o nome da versão (não se aplica a 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. Receba 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 recurso compute ou app-engine)
    • VERSION: o nome da versão (não se aplica a compute, opcional para app-engine)

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

Acesso por navegador

Para permitir que o IAP use o ID e a chave secreta do cliente no 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 é um risco operacional, não de segurança. Com os controles de acesso e o monitoramento adequados, a conveniência e os benefícios de gerenciamento de 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 e os criados a partir 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.
  • Implementar o gerenciamento seguro de credenciais usando o Secret Manager
  • Monitorar 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 vazou, redefina-o imediatamente.

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

Considerações sobre o escopo da 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 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 precisará de 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.