Como partilhar clientes OAuth

Esta página explica como partilhar um cliente OAuth com outra aplicação na sua organização.

Vista geral

A partilha de clientes OAuth entre projetos significa usar um único cliente OAuth personalizado para várias aplicações protegidas pelo Identity-Aware Proxy (IAP), em vez de criar um novo cliente OAuth para cada aplicação. Esta abordagem simplifica a gestão, especialmente para organizações com muitas aplicações.

Quando configura a IAP, pode usar um de dois tipos de cliente OAuth:

  • Cliente OAuth gerido pela Google: o IAP usa automaticamente esta opção por predefinição. Esta opção integrada não requer a criação manual de clientes, mas tem duas limitações importantes:

    • Só permite o acesso a utilizadores na sua organização (utilizadores internos)
    • Apresenta o Google Cloud branding no ecrã de consentimento em vez do branding da sua organização

  • Cliente OAuth personalizado: é criado e gerido por si. Esta opção:

    • Podem ser partilhados por várias aplicações
    • Permite a personalização do branding no ecrã de consentimento
    • Suporta o acesso de utilizadores externos (fora da sua organização)

Quando cria um cliente OAuth personalizado, tem a flexibilidade de o usar com uma única aplicação ou partilhá-lo em várias aplicações. A partilha de um cliente OAuth personalizado oferece várias vantagens:

  • Reduz a sobrecarga administrativa da gestão de vários clientes
  • Simplifica a ativação da IAP para os membros da equipa que não devem ter acesso à página Credenciais
  • Facilita o acesso programático (não baseado no navegador) a aplicações protegidas pela IAP

Para informações sobre como criar clientes OAuth, consulte o artigo Criar clientes OAuth para a IAP. Para ver detalhes sobre os clientes OAuth geridos pela Google, consulte o artigo Personalize uma configuração OAuth para ativar a IAP.

Antes de começar

Crie um novo cliente OAuth seguindo os passos em Criação de cliente OAuth ou use um cliente OAuth existente.

Acesso programático

Configure clientes OAuth para acesso programático para permitir que as aplicações que não sejam de navegador se autentiquem com os seus recursos protegidos pelo IAP. Isto permite que os scripts, as tarefas automatizadas e os serviços de back-end acedam em segurança às suas aplicações protegidas sem início de sessão interativo do utilizador.

Pode aplicar estas definições de autenticação a qualquer nível na hierarquia de recursos: organização, pasta ou projeto.

Para ver os passos de implementação, consulte o guia de autenticação programática e a documentação de gestão das definições de IAP.

gcloud

  1. Prepare um ficheiro de definições com os seus IDs de cliente OAuth:

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

  2. Aplique as definições através do 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

    Onde:

    • SETTINGS_FILENAME: o ficheiro YAML que 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 os 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 ficheiro JSON de definições:

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

  2. Obtenha 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 definições através do 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"

    Onde:

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

Após a configuração, inicie sessão na aplicação com qualquer um dos IDs de cliente OAuth que configurou. Consulte o artigo Autenticação programática para ver detalhes.

Acesso através do navegador

Para permitir que a IAP use o seu ID de cliente e segredo através da Google Cloud consola, conclua as seguintes instruções:

Riscos

Embora a partilha de um cliente entre as suas aplicações seja conveniente, existem riscos. Esta secção descreve os potenciais riscos da partilha de clientes e como os mitigar.

Ponto único de falha

A utilização de um cliente OAuth para muitas aplicações cria um único ponto de dependência. Se um cliente for eliminado ou modificado incorretamente, todas as aplicações que usam esse cliente são afetadas. Os clientes OAuth eliminados podem ser restaurados no prazo de 30 dias.

Para gerir este risco operacional de forma eficaz:

  • Implemente controlos de acesso adequados para evitar alterações ou eliminações acidentais
  • Restrinja o acesso a clientes OAuth através das autorizações clientauthconfig.clients.*
  • Use os Google Cloud registos de auditoria para acompanhar as atividades administrativas que envolvem clientes OAuth

Este é principalmente um risco operacional e não um risco de segurança. Com os controlos de acesso e a monitorização adequados, as vantagens de gestão e conveniência dos clientes OAuth partilhados normalmente superam esta consideração.

Fugas de segredos do cliente

A partilha de um cliente requer a partilha do segredo do cliente com pessoas e scripts. Isto aumenta o risco de o segredo do cliente ser divulgado. As CNA não conseguem distinguir entre tokens criados a partir da sua aplicação e tokens criados a partir de um segredo do cliente divulgado.

Para mitigar este risco:

  • Proteja os segredos do cliente, como palavras-passe, e nunca os armazene como texto simples
  • Implemente a gestão segura de credenciais com o Secret Manager
  • Monitorize o acesso aos seus recursos do IAP com o Cloud Audit Logging
  • Um segredo do cliente divulgado afeta apenas a autenticação e não a autorização para aceder a recursos. Se suspeitar que o seu segredo foi divulgado, reponha-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 partilhar segredos do cliente OAuth com utilizadores individuais. Esta abordagem oferece um melhor isolamento de segurança, ao mesmo tempo que mantém as vantagens de um cliente OAuth partilhado para as suas aplicações.

Considerações sobre o âmbito da autorização

Quando partilham clientes OAuth, todas as aplicações usam os mesmos âmbitos de autorização. Para a IAP, openid e email são os únicos âmbitos obrigatórios. Esta consideração por si só não representa um risco significativo, mas é importante compreender:

  • O OAuth é usado apenas para autenticação (validação da identidade) na IAP. A autorização (acesso a recursos) é processada separadamente através das políticas de IAM
  • Mesmo que as credenciais de autenticação sejam comprometidas, um atacante continua a precisar de autorizações de IAM adequadas para aceder a recursos protegidos
  • Restringir o cliente apenas aos âmbitos openid e email necessários ajuda a limitar o potencial impacto na segurança