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 (Authentication) 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 Protected App funktioniert​

Die Protected App, unterstützt durch Cloudflare, arbeitet weltweit auf Edge-Netzwerken und sorgt so für geringe Latenz und hohe Verfügbarkeit deiner Anwendung.

Die Protected App verwaltet den Sitzungsstatus und die Benutzerinformationen. Ist ein Benutzer nicht authentifiziert, leitet die Protected App ihn zur Anmeldeseite weiter. Nach erfolgreicher Authentifizierung 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 und nicht der Protected App von Logto gehört, ist der Ort, an dem sich deine Anwendungsinhalte befinden. Ähnlich wie ein Content Delivery Network (CDN)-Server verwaltet die Protected App die 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.

Daher ist es wichtig, die Ursprungsverbindungen abzusichern, 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 Token (JWT)-Validierung

HTTP-Header-Validierung​

Die Absicherung deines Ursprungsservers kann durch HTTP Basic Authentifizierung erfolgen.

Jede Anfrage von der Protected App enthält 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 die folgenden Anleitungen nutzen, um HTTP Basic Authentifizierung auf deinem Ursprungsserver zu implementieren:

  1. Nginx: HTTP Basic Authentifizierung konfigurieren
  2. Apache: Authentifizierung und Autorisierung

Um die Header innerhalb deiner Anwendung zu prüfen, siehe das HTTP Basic Authentication Beispiel von Cloudflare, um zu lernen, wie du den Zugriff mit dem HTTP Basic Schema einschränkst.

JSON Web Token (JWT)-Validierung​

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

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

Logto-ID-Token: <JWT>

Das JWT wird als ID-Token (ID token) bezeichnet, 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 verschlüsselt und als JWS-Token signiert.

Die Validierungsschritte:

  1. Ein JWT validieren
  2. Die JWS-Signatur validieren
  3. Der Aussteller (Issuer) 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 enthält
  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('Hallo Welt!');
});

app.listen(3000);

Authentifizierungsstatus und Benutzerinformationen abrufen​

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

Wenn du das Token nur dekodieren möchtest, kannst du 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);

ID-Token-Ansprüche anpassen​

Standardmäßig enthält der Logto-ID-Token Header die Standard-OIDC-Ansprüche (z. B. sub, name und email). Um erweiterte Ansprüche wie Rollen oder Organisationsdaten einzuschließen, müssen beide folgenden Punkte konfiguriert werden:

  1. Mandanten-Umschalter: Aktiviere den Anspruch in Konsole > Custom JWT > ID-Token.
  2. Protected App Scopes: Wähle in deinen Protected App Einstellungen den passenden Scope unter ID-Token-Ansprüche > Zusätzliche Scopes aus.

Erweiterte Ansprüche werden nur dann im weitergeleiteten ID-Token enthalten, wenn der Anspruch in Custom JWT aktiviert und der entsprechende Scope für die Protected App ausgewählt ist. Siehe Custom ID-Token für die vollständige Liste der erweiterten Scopes und Ansprüche.

ScopeAnsprüche
custom_datacustom_data
identitiesidentities, sso_identities
rolesroles
urn:logto:scope:organizationsorganizations, organization_data
urn:logto:scope:organization_rolesorganization_roles

Den ursprünglichen Host abrufen​

Wenn du den ursprünglichen Host benötigst, der vom Client angefragt 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 möchtest, kannst du das Feld „Benutzerdefinierte Authentifizierungsregeln“ in der Konsole setzen.

Es werden reguläre Ausdrücke unterstützt, hier zwei Anwendungsfälle:

  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. Ist dein Ursprungsserver jedoch nicht öffentlich erreichbar, kannst du ein Tool wie ngrok oder Cloudflare Tunnels verwenden, um deinen lokalen Server ins Internet zu bringen.

Umstieg auf SDK-Integration​

Die Protected App wurde entwickelt, um den Authentifizierungsprozess zu vereinfachen. Wenn du jedoch für mehr Kontrolle und Anpassung auf eine SDK-Integration umsteigen möchtest, kannst du eine neue Anwendung erstellen und die SDK-Integration konfigurieren. Für einen reibungslosen Übergang kannst du die Anwendungskonfigurationen aus der Protected App wiederverwenden. Die Protected App ist tatsächlich eine „Traditionelle Web-App“ in Logto, du findest die "AppId" und "AppSecret" in den Anwendungseinstellungen. Nach Abschluss des Umstiegs 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