PERMISSIONS / TECHNICAL DESIGN

Autorisierung und API-Integration

Durch die Authentifizierung wird der Anforderer identifiziert. Die Autorisierung bestimmt erlaubte Aktionen. Überprüfen Sie die Aufzeichnung und den Zweck jedes Vorgangs.

Nur erlauben, wenn alle Bedingungen erfüllt sind

Prüfen Sie den authentifizierten Akteur und Mandanten, die angeforderte Aktion, den Datensatz und die Gültigkeit der Berechtigung. Fehlen erforderliche Bedingungen, wird die Anfrage standardmäßig abgelehnt.

Akteur: Der authentifizierte Dienst oder Partner. Vertrauen Sie client_id im Anfragekörper nicht.
Datensatz: Beschränken Sie Datensätze auf die authentifizierte tenant_id.
Aktion und Zweck: Prüfen Sie Berechtigungen wie shipping.address.read und den zugehörigen Lieferzweck.
Zusätzliche Bedingungen: Prüfen Sie Empfänger, Ablauf, Widerruf, Nutzungszahl und Beziehung zur Person.
Konsistente Entscheidungen: Berücksichtigen Sie Zustandsänderungen zwischen Autorisierung, Datenabruf und Aktualisierung der Nutzungszahl.

Dienstauthentifizierung und Zugangsnachweise

Verwenden Sie Microsoft-Entra-Anwendungs-Bearer-Token: Managed Identity in Azure oder einen privaten Zertifikatsschlüssel zur Tokenanforderung. Das ist keine mTLS-Authentifizierung. Der aktuelle Vault vertraut einem Entra-Verzeichnis; andere Organisationen sind nicht automatisch zugelassen. Zugangsdaten bleiben im Backend.

Empfängerbeschränkungen: Prüfen Sie den vorgesehenen Token-Empfänger und das Ziel. Lehnen Sie für andere APIs ausgestellte Tokens ab.
Rotation der Zugangsnachweise: Regeln Sie die Stilllegung alter Zugangsnachweise und den Übergangszeitraum.
Browser- und Server-Zugangsnachweise trennen: Betten Sie Server-Zugangsnachweise niemals in JavaScript oder HTML ein.

Fehler, Wiederholungen und Audit

Protokollieren Sie Ablehnungsgründe intern, ohne Datensätze anderer Mandanten oder personenbezogene Daten offenzulegen. Ist das Ergebnis nach einem Timeout unklar, verwenden Sie Idempotenzschlüssel oder Statusabfragen statt blinder Wiederholungen.

401 / 403: Unterscheiden Sie fehlende Authentifizierung von fehlender Autorisierung. Halten Sie Details in geschützten internen Protokollen fest.
404: Erwägen Sie identische Antworten für nicht vorhandene und nicht autorisierte Datensätze.
409 / 429: Idempotenzkonflikte und Anfragelimits. Definieren Sie Wiederholungsregeln und Wartezeiten.
503: Kann der Berechtigungs- oder Widerrufszustand nicht geprüft werden, stoppen Sie die Verarbeitung, statt die Anfrage als autorisiert zu behandeln.

DATA / INTEGRATION EXAMPLE

Daten- und Integrationsbeispiel

Diese Beispiele erläutern das Konzept. Feldnamen und Werte dienen der Veranschaulichung und sind keine ausführbare API-Referenz.

{
  "operation": "Authorization inputs and decision example",
  "authenticated_context": {
    "tenant_id": "tenant_a",
    "client_id": "carrier-a"
  },
  "request": {
    "action": "shipping.address.read",
    "resource_ref": "order_example_01",
    "purpose": "fulfillment"
  },
  "decision": {
    "allowed": true,
    "fields": [
      "postal_code",
      "address",
      "recipient_name"
    ],
    "decision_id": "dec_example_01"
  }
}

Leiten Sie den Authentifizierungskontext aus geprüften Zugangsnachweisen ab. Eine vom Client übermittelte tenant_id darf niemals als Berechtigungsgrundlage dienen.

Integration für Ihre Arbeitsabläufe.

Erfassen Sie gespeicherte Daten, Partner und erforderliche Aktionen, um Möglichkeiten zur Reduzierung der Datenexposition zu erkennen.

Besprechen Sie die technische Integration