Pular para o conteúdo principal

Protected App — Integração de autenticação sem SDK

O Protected App foi projetado para eliminar a complexidade das integrações de SDK ao separar a camada de autenticação da sua aplicação. Nós cuidamos da autenticação, permitindo que você foque na sua funcionalidade principal. Uma vez que um usuário é autenticado, o Protected App serve o conteúdo do seu servidor.

Como o Protected App funciona​

O Protected App, alimentado pela Cloudflare, opera globalmente em redes de borda, garantindo baixa latência e alta disponibilidade para sua aplicação.

O Protected App mantém o estado da sessão e as informações do usuário. Se um usuário não estiver autenticado, o Protected App o redireciona para a página de login. Uma vez autenticado, o Protected App encapsula a solicitação do usuário com autenticação e informações do usuário, e então a encaminha para o servidor de origem.

Esse processo é visualizado no fluxograma a seguir:

Proteja seu servidor de origem​

O servidor de origem, que pode ser um dispositivo físico ou virtual não pertencente ao Protected App do Logto, é onde o conteúdo da sua aplicação reside. Semelhante a um servidor de Content Delivery Network (CDN), o Protected App gerencia os processos de autenticação e recupera o conteúdo do seu servidor de origem. Portanto, se os usuários obtiverem acesso direto ao seu servidor de origem, eles podem contornar a autenticação e sua aplicação não estará mais protegida.

Por isso, é importante proteger as conexões de origem, pois isso impede que invasores descubram e acessem seu servidor de origem sem autenticação. Existem várias maneiras de fazer isso:

  1. Validação de cabeçalho HTTP
  2. Validação de JSON Web Tokens (JWT)

Validação de cabeçalho HTTP​

Proteger seu servidor de origem pode ser feito usando HTTP Basic Authentication.

Cada requisição do Protected App inclui o seguinte cabeçalho:

Authorization: Basic base64(appId:appSecret)

Ao validar esse cabeçalho, você pode confirmar que a requisição vem do Protected App e negar qualquer requisição que não inclua esse cabeçalho.

Se você estiver usando Nginx ou Apache, pode consultar os seguintes guias para implementar HTTP Basic Authentication em seu servidor de origem:

  1. Nginx: Configurando HTTP Basic Authentication
  2. Apache: Authentication and Authorization

Para verificar os cabeçalhos dentro da sua aplicação, consulte o exemplo de HTTP Basic Authentication fornecido pela Cloudflare para aprender como restringir o acesso usando o esquema HTTP Basic.

Validação de JSON Web Tokens (JWT)​

Outra forma de proteger seu servidor de origem é usando JSON Web Tokens (JWT).

Cada requisição autenticada do Protected App inclui o seguinte cabeçalho:

Logto-ID-Token: <JWT>

O JWT é chamado de Token de ID (ID token), assinado pelo Logto e contém informações do usuário. Ao validar esse JWT, você pode confirmar que a requisição vem do Protected App e negar qualquer requisição que não inclua esse cabeçalho.

O token é criptografado e assinado como um token JWS.

Os passos de validação:

  1. Validando um JWT
  2. Validando a assinatura JWS
  3. O emissor do token é https://<your-logto-domain>/oidc (emitido pelo seu servidor de autenticação Logto)
const express = require('express');
const jwksClient = require('jwks-rsa');
const jwt = require('jsonwebtoken');

const ISSUER = 'https://<your-logto-domain>/oidc';
const CERTS_URL = 'https://<your-logto-domain>/oidc/jwks';

const client = jwksClient({
  jwksUri: CERTS_URL,
});

const getKey = (header, callback) => {
  client.getSigningKey(header.kid, function (err, key) {
    callback(err, key?.getPublicKey());
  });
};

const verifyToken = (req, res, next) => {
  const token = req.headers['Logto-ID-Token'];

  // Certifique-se de que a requisição recebida possui nosso cabeçalho de token
  if (!token) {
    return res
      .status(403)
      .send({ status: false, message: 'cabeçalho Logto-ID-Token obrigatório ausente' });
  }

  jwt.verify(token, getKey, { issuer: ISSUER }, (err, decoded) => {
    if (err) {
      return res.status(403).send({ status: false, message: 'token de ID inválido' });
    }

    req.user = decoded;
    next();
  });
};

const app = express();

app.use(verifyToken);

app.get('/', (req, res) => {
  res.send('Olá Mundo!');
});

app.listen(3000);

Obtenha o estado de autenticação e informações do usuário​

Se você precisar obter informações de autenticação e do usuário para sua aplicação, também pode usar o cabeçalho Logto-ID-Token.

Se você quiser apenas decodificar o token, pode usar o seguinte código:

const express = require('express');

const decodeIdToken = (req, res, next) => {
  const token = req.headers['Logto-ID-Token'];

  if (!token) {
    return res.status(403).send({
      status: false,
      message: 'cabeçalho Logto-ID-Token obrigatório ausente',
    });
  }

  const parts = token.split('.');
  if (parts.length !== 3) {
    throw new Error('Token de ID inválido');
  }

  const payload = parts[1];
  const decodedPayload = atob(payload.replace(/-/g, '+').replace(/_/g, '/'));
  const claims = JSON.parse(decodedPayload);

  req.user = claims;
  next();
};

const app = express();

app.use(decodeIdToken);

app.get('/', (req, res) => {
  res.json(req.user);
});

app.listen(3000);

Personalize as reivindicações do token de ID​

Por padrão, o cabeçalho Logto-ID-Token inclui reivindicações padrão do OIDC (por exemplo, sub, name e email). Para incluir reivindicações estendidas como papéis ou dados da organização, ambos os itens a seguir devem ser configurados:

  1. Alternância do tenant: Ative a reivindicação em Console > Custom JWT > ID token.
  2. Escopos do Protected App: Nas configurações do seu Protected App, selecione o escopo correspondente em ID token claims > Additional scopes.

As reivindicações estendidas são incluídas no token de ID encaminhado somente quando a reivindicação está ativada no Custom JWT e o escopo correspondente está selecionado para o Protected App. Veja Custom ID token para a lista completa de escopos e reivindicações estendidas.

EscopoReivindicações
custom_datacustom_data
identitiesidentities, sso_identities
rolesroles
urn:logto:scope:organizationsorganizations, organization_data
urn:logto:scope:organization_rolesorganization_roles

Obtenha o host original​

Se você precisar obter o host original solicitado pelo cliente, pode usar o cabeçalho Logto-Host ou x-forwarded-host.

Personalize as regras de autenticação​

Por padrão, o Protected App protegerá todas as rotas. Se você precisar personalizar as regras de autenticação, pode definir o campo "Custom authentication rules" no Console.

Ele suporta expressões regulares, aqui estão dois cenários de uso:

  1. Para proteger apenas as rotas /admin e /privacy com autenticação: ^/(admin|privacy)/.*
  2. Para excluir imagens JPG da autenticação: ^(?!.*\.jpg$).*$

Desenvolvimento local​

O Protected App foi projetado para funcionar com seu servidor de origem. No entanto, se seu servidor de origem não for acessível publicamente, você pode usar uma ferramenta como ngrok ou Cloudflare Tunnels para expor seu servidor local à internet.

Transição para integração com SDK​

O Protected App foi projetado para simplificar o processo de autenticação. No entanto, se você decidir migrar para a integração com SDK para obter mais controle e personalização, pode criar um novo aplicativo no Logto e configurar a integração com SDK. E para uma transição suave, você pode reutilizar as configurações do aplicativo do Protected App. O Protected App é, na verdade, um "Traditional Web App" no Logto, você pode encontrar o "AppId" e o "AppSecret" nas configurações do aplicativo. Após a conclusão da transição, você pode remover o Protected App da sua aplicação.

Protected App: construa a autenticação do seu app em poucos cliques. Sem código.

 A motivação por trás do Protected App

A maneira mais rápida de construir um sistema de autenticação