Usar o Firebase para autenticar utilizadores

Esta página descreve como suportar a autenticação de utilizadores no Cloud Endpoints.

Para autenticar um utilizador, uma aplicação cliente tem de enviar um token da Web JSON (JWT) no cabeçalho de autorização do pedido HTTP para a sua API de back-end. O proxy de serviço extensível (ESP) valida o token em nome da sua API, pelo que não tem de adicionar código na sua API para processar a autenticação. No entanto, tem de configurar o seu documento OpenAPI para suportar os métodos de autenticação escolhidos.

O ESP valida um JWT de forma eficiente através das chaves públicas do emissor do JWT. O ESP armazena em cache as chaves públicas durante cinco minutos. Além disso, o ESP armazena em cache os JWTs validados durante cinco minutos ou até à expiração do JWT, consoante o que ocorrer primeiro.

Antes de começar

  • Adicione o código de autenticação à sua aplicação cliente seguindo a documentação de autenticação do Firebase. O Firebase suporta a autenticação através de palavras-passe, números de telefone e fornecedores de identidade federada populares, como a Google, o Facebook e o Twitter.

  • Quando a sua aplicação cliente envia um pedido HTTP, o cabeçalho de autorização no pedido tem de conter as seguintes reivindicações JWT:
    • iss (emissor)
    • sub (assunto)
    • aud (público-alvo)
    • iat (emitido em)
    • exp (hora de expiração)

Configurar o seu documento OpenAPI

Tem de ter um objeto de requisito de segurança e um objeto de definições de segurança no seu documento OpenAPI para que o ESP valide as reivindicações no JWT assinado.

Para suportar a autenticação do Firebase:

  1. Adicione o seguinte à definição de segurança no seu documento OpenAPI:

      securityDefinitions:
    firebase:
      authorizationUrl: ""
      flow: "implicit"
      type: "oauth2"
      # Replace YOUR-PROJECT-ID with your project ID
      x-google-issuer: "https://securetoken.google.com/YOUR-PROJECT-ID"
      x-google-jwks_uri: "https://www.googleapis.com/service_accounts/v1/metadata/x509/securetoken@system.gserviceaccount.com"
      x-google-audiences: "YOUR-PROJECT-ID"

  2. Adicione uma secção de segurança ao nível da API para aplicar a toda a API ou ao nível do método para aplicar a um método específico.

      security:
    - firebase: []

Pode definir várias definições de segurança no documento OpenAPI, mas cada definição tem de ter um emissor diferente. Se usar secções de segurança ao nível da API e ao nível do método, as definições ao nível do método substituem as definições ao nível da API.

Também pode personalizar as localizações de JWT adicionando x-google-extensions. Para ver detalhes, consulte as extensões da API openAPI.

Fazer uma chamada autenticada para uma API Endpoints

Quando envia um pedido através de um token de autenticação, por motivos de segurança, recomendamos que coloque o token no cabeçalho Authorization:Bearer. Por exemplo:

curl -H "Authorization: Bearer ${TOKEN}" "${ENDPOINTS_HOST}/echo"

Aqui, ENDPOINTS_HOST e TOKEN são variáveis de ambiente que contêm o nome do anfitrião da API e o token de autenticação, respetivamente. Consulte o artigo Fazer um pedido autenticado a uma API Endpoints. para ver um exemplo de código que envia um pedido usando o cabeçalho Authorization:Bearer.

Se não puder usar o cabeçalho ao enviar o pedido, pode colocar o token de autenticação num parâmetro de consulta denominado access_token. Por exemplo:

curl "${ENDPOINTS_HOST}/echo?access_token=${TOKEN}"

Receber resultados autenticados na sua API

Normalmente, o ESP encaminha todos os cabeçalhos que recebe. No entanto, substitui o cabeçalho Authorization original quando o endereço de back-end é especificado por x-google-backend na especificação OpenAPI ou BackendRule na configuração do serviço gRPC.

O ESP envia o resultado da autenticação no cabeçalho X-Endpoint-API-UserInfo para a API de back-end. Recomendamos que use este cabeçalho em vez do cabeçalho Authorization original. Este cabeçalho é uma string que base64urlcodifica um objeto JSON. O formato do objeto JSON difere entre o ESPv2 e o ESP. Para o ESPv2, o objeto JSON é exatamente o payload JWT original. Para o ESP, o objeto JSON usa nomes de campos diferentes e coloca o payload JWT original no campo claims. Consulte o artigo Processar JWTs no serviço de back-end para mais informações sobre o formato.

O que se segue?