Zum Hauptinhalt springen

Protected App — Nicht-SDK-Authentifizierungsintegration

Die Protected App wurde entwickelt, um die Komplexität von SDK-Integrationen zu beseitigen, indem die Authentifizierung von deiner Anwendung getrennt wird. Wir übernehmen die Authentifizierung, sodass du dich auf deine Kernfunktionalität konzentrieren kannst. Sobald ein Benutzer authentifiziert ist, liefert die Protected App die Inhalte von deinem Server aus.

Wie die Protected App funktioniert​

Die von Cloudflare unterstützte Protected App arbeitet global auf Edge-Netzwerken und gewährleistet niedrige Latenz und hohe Verfügbarkeit für deine Anwendung.

Die Protected App verwaltet den Sitzungsstatus und die Benutzerinformationen. Wenn ein Benutzer nicht authentifiziert ist, leitet die Protected App ihn zur Anmeldeseite weiter. Sobald er authentifiziert ist, versieht die Protected App die Anfrage des Benutzers mit Authentifizierungs- und Benutzerinformationen und leitet sie dann an den Ursprungsserver weiter.

Dieser Prozess wird im folgenden Flussdiagramm visualisiert:

Schütze deinen Ursprungsserver​

Der Ursprungsserver, der entweder ein physisches oder virtuelles Gerät sein kann, das nicht von Logto's Protected App verwaltet wird, ist der Ort, an dem deine Anwendungsinhalte gespeichert sind. Ähnlich wie ein Content Delivery Network (CDN)-Server verwaltet die Protected App Authentifizierungsprozesse und ruft Inhalte von deinem Ursprungsserver ab. Wenn Benutzer jedoch direkten Zugriff auf deinen Ursprungsserver erhalten, können sie die Authentifizierung umgehen und deine Anwendung ist nicht mehr geschützt.

Es ist daher wichtig, Ursprungsverbindungen zu sichern, um zu verhindern, dass Angreifer deinen Ursprungsserver ohne Authentifizierung entdecken und darauf zugreifen. Es gibt mehrere Möglichkeiten, dies zu tun:

  1. HTTP-Header-Validierung
  2. JSON Web Tokens (JWT) Validierung

HTTP-Header-Validierung​

Die Sicherung deines Ursprungsservers kann durch die Verwendung von HTTP Basic Authentication erreicht werden.

Jede Anfrage von der Protected App enthält den folgenden Header:

Authorization: Basic base64(appId:appSecret)

Durch die Validierung dieses Headers kannst du bestätigen, dass die Anfrage von der Protected App stammt, und alle Anfragen ablehnen, die diesen Header nicht enthalten.

Wenn du Nginx oder Apache verwendest, kannst du auf die folgenden Anleitungen verweisen, um HTTP Basic Authentication auf deinem Ursprungsserver zu implementieren:

  1. Nginx: Konfigurieren von HTTP Basic Authentication
  2. Apache: Authentifizierung und Autorisierung

Um die Header innerhalb deiner Anwendung zu überprüfen, kannst du das von Cloudflare bereitgestellte HTTP Basic Authentication Beispiel verwenden, um zu lernen, wie man den Zugriff mit dem HTTP Basic Schema einschränkt.

JSON Web Tokens (JWT) Validierung​

Eine weitere Möglichkeit, deinen Ursprungsserver zu sichern, ist die Verwendung von JSON Web Tokens (JWT).

Jede authentifizierte Anfrage von der Protected App enthält den folgenden Header:

Logto-ID-Token: <JWT>

Das JWT wird ID-Token genannt, das von Logto signiert ist und Benutzerinformationen enthält. Durch die Validierung dieses JWT kannst du bestätigen, dass die Anfrage von der Protected App stammt, und alle Anfragen ablehnen, die diesen Header nicht enthalten.

Das Token ist als JWS Token verschlüsselt und signiert.

Die Validierungsschritte:

  1. Validierung eines JWT
  2. Validierung der JWS-Signatur
  3. Der Aussteller des Tokens ist https://<your-logto-domain>/oidc (ausgestellt von deinem Logto-Auth-Server)
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'];

  // Stelle sicher, dass die eingehende Anfrage unseren Token-Header hat
  if (!token) {
    return res
      .status(403)
      .send({ status: false, message: 'fehlender erforderlicher Logto-ID-Token-Header' });
  }

  jwt.verify(token, getKey, { issuer: ISSUER }, (err, decoded) => {
    if (err) {
      return res.status(403).send({ status: false, message: 'ungültiges ID-Token' });
    }

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

const app = express();

app.use(verifyToken);

app.get('/', (req, res) => {
  res.send('Hello World!');
});

app.listen(3000);

Authentifizierungsstatus und Benutzerinformationen abrufen​

Wenn du Authentifizierungs- und Benutzerinformationen für deine Anwendung benötigst, kannst du auch den Logto-ID-Token Header verwenden.

Wenn du das Token nur dekodieren möchtest, kannst du den folgenden Code verwenden:

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: 'fehlender erforderlicher Logto-ID-Token-Header',
    });
  }

  const parts = token.split('.');
  if (parts.length !== 3) {
    throw new Error('Ungültiges ID-Token');
  }

  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);

Den ursprünglichen Host abrufen​

Wenn du den ursprünglichen Host abrufen musst, der vom Client angefordert wurde, kannst du den Logto-Host oder x-forwarded-host Header verwenden.

Authentifizierungsregeln anpassen​

Standardmäßig schützt die Protected App alle Routen. Wenn du die Authentifizierungsregeln anpassen musst, kannst du das Feld "Benutzerdefinierte Authentifizierungsregeln" in der Konsole festlegen.

Es unterstützt reguläre Ausdrücke, hier sind zwei Fallbeispiele:

  1. Um nur die Routen /admin und /privacy mit Authentifizierung zu schützen: ^/(admin|privacy)/.*
  2. Um JPG-Bilder von der Authentifizierung auszuschließen: ^(?!.*\.jpg$).*$

Lokale Entwicklung​

Die Protected App ist darauf ausgelegt, mit deinem Ursprungsserver zu arbeiten. Wenn dein Ursprungsserver jedoch nicht öffentlich zugänglich ist, kannst du ein Tool wie ngrok oder Cloudflare Tunnels verwenden, um deinen lokalen Server im Internet verfügbar zu machen.

Übergang zur SDK-Integration​

Die Protected App wurde entwickelt, um den Authentifizierungsprozess zu vereinfachen. Wenn du jedoch zur SDK-Integration für bessere Kontrolle und Anpassung wechseln möchtest, kannst du eine neue Anwendung erstellen in Logto und die SDK-Integration konfigurieren. Für einen reibungslosen Übergang kannst du die Anwendungskonfigurationen von der Protected App wiederverwenden. Die Protected App ist tatsächlich eine "Traditionelle Web-App" in Logto, du kannst die "AppId" und "AppSecret" in den Anwendungseinstellungen finden. Nach Abschluss des Übergangs kannst du die Protected App aus deiner Anwendung entfernen.

Protected App: Baue die Authentifizierung deiner App in wenigen Klicks. Kein Code erforderlich.

 Die Motivation hinter der Protected App

Der schnellste Weg, ein Authentifizierungssystem zu bauen