Endpunktreferenz: http-API für Microsoft Entra ID Auth SDK (Sidecar)

Dieses Dokument enthält vollständige Referenz zu den HTTP-Endpunkten, die vom Microsoft Entra ID Auth SDK (Sidecar) verfügbar gemacht werden.

API-Spezifikation

OpenAPI-Spezifikation: Verfügbar unter /openapi/v1.json (Entwicklungsumgebung) und im Repository: https://github.com/AzureAD/microsoft-identity-web/blob/master/src/Microsoft.Identity.Web.Sidecar/OpenAPI/Microsoft.Identity.Web.Sidecar.json

Verwenden Sie es zu folgenden Zwecken:

• Generieren von Clientcode
• Überprüfen von Anforderungen
• Ermitteln verfügbarer Endpunkte

Endpunktübersicht

Authentifizierung

Bearer bleibt das Standardauthentifizierungsschema für authentifizierte Endpunkte. Der /Validate Endpunkt akzeptiert außerdem das PoP Schema für Anmeldeinformationen für nur signierte HTTP-Anforderung (Signed HTTP Request, SHR). Andere authentifizierte Endpunkte erfordern Bearer, es sei denn, explizit als nicht authentifiziert gekennzeichnet:

GET /AuthorizationHeader/Graph
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGc...

Token werden anhand konfigurierter Microsoft Entra ID Einstellungen überprüft, einschließlich Mandant, Zielgruppe, Aussteller und Bereiche, wenn diese aktiviert sind. Bei PoP-Anforderungen überprüft das Sidecar die SHR-Signatur und das eingebettete Zugriffstoken für denselben Mandanten, die Zielgruppe, den Aussteller und die Signaturschlüsselkonfiguration.

/Validate

Überprüft ein eingehendes Bearertoken oder nur app-only SHR PoP-Anmeldeinformationen und gibt das überprüfte Token und seine Ansprüche zurück.

Anfrage

Beareranforderung:

GET /Validate HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGc...

PoP-Anforderung:

GET /Validate HTTP/1.1
Authorization: PoP <signed-http-request>
original-method: GET
original-uri: https://api.contoso.com/data

Für PoP original-method und original-uri sind erforderlich. Sie müssen die Methode und den absoluten URI der ursprünglichen Anforderung enthalten, über die die SHR-Anmeldeinformationen signiert wurden. Das Sidecar verwendet diese Werte, um die Anforderungsbindung zu überprüfen; die /Validate Anforderung selbst ist nicht die signierte Ressourcenanforderung.

Erfolgreiche Antwort (200)

{
  "protocol": "Bearer",
  "token": "eyJ0eXAiOiJKV1QiLCJhbGc...",
  "claims": {
    "aud": "api://your-api-id",
    "iss": "https://sts.windows.net/tenant-id/",
    "iat": 1234567890,
    "nbf": 1234567890,
    "exp": 1234571490,
    "acr": "1",
    "appid": "client-id",
    "appidacr": "1",
    "idp": "https://sts.windows.net/tenant-id/",
    "oid": "user-object-id",
    "tid": "tenant-id",
    "scp": "access_as_user",
    "sub": "subject",
    "ver": "1.0"
  }
}

Der protocol Wert gilt Bearer für eine Bearer-Anforderung und PoP für eine PoP-Anforderung. Enthält für PoP token das in die signierte HTTP-Anforderung eingebettete validierte Zugriffstoken. Die zurückgegebenen Ansprüche hängen von der Zugriffstokenversion und mandantenkonfiguration ab.

Beispiele für Fehler

Fehlende Autorisierungsanmeldeinformationen werden abgelehnt, bevor der Endpunkt ausgeführt wird:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer

Ein ungültiges Bearertoken gibt eine Bearer-Abfrage zurück:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token"

Eine fehlgeschlagene PoP-Anforderung enthält die folgende Herausforderung. Da /Validate beide Authentifizierungsschemas akzeptiert werden, kann die Antwort auch die Bearer-Abfrage enthalten.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: PoP error="invalid_token"

/AuthorizationHeader/{serviceName}

Ruft ein Zugriffstoken für die konfigurierte downstream-API ab und gibt es als Autorisierungsheaderwert zurück. Wenn ein Benutzer bearertoken eingehend bereitgestellt wird, wird OBO (delegiert) verwendet; andernfalls gelten App-Kontextmuster (sofern aktiviert).

Path-Parameter

• serviceName – Name der downstream-API in der Konfiguration

Abfrageparameter

Standardüberschreibungen

Agentidentität

Regeln:

• AgentUsername oder AgentUserId erfordern AgentIdentity (Benutzer-Agent).
• AgentUsername und AgentUserId schließen sich gegenseitig aus.
• AgentIdentity allein = autonomer Agent.
• AgentIdentity + Benutzereingangstoken = delegierter Agent.

Examples

Grundlegende Anforderung:

GET /AuthorizationHeader/Graph HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGc...

GET /AuthorizationHeader/Graph?optionsOverride.RequestAppToken=true HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGc...

GET /AuthorizationHeader/Graph?AgentIdentity=agent-id HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGc...

Antwort

{
  "authorizationHeader": "Bearer eyJ0eXAiOiJKV1QiLCJhbGc..."
}

PoP/SHR-Antwort:

{
  "authorizationHeader": "PoP eyJ0eXAiOiJhdCtqd3QiLCJhbGc..."
}

/AuthorizationHeaderUnauthenticated/{serviceName}

Dasselbe Verhalten und dieselben Parameter wie /AuthorizationHeader/{serviceName} ein eingehendes Benutzertoken wird erwartet. Wird ohne Benutzerkontext für app-only oder autonome/Agent-Identitätsakquisition verwendet. Verhindert den Aufwand für die Überprüfung eines Benutzertokens.

Anfrage

GET /AuthorizationHeaderUnauthenticated/Graph HTTP/1.1

Antwort

{
  "authorizationHeader": "Bearer eyJ0eXAiOiJKV1QiLCJhbGc..."
}

/DownstreamApi/{serviceName}

Erwirbt ein Zugriffstoken und führt eine HTTP-Anforderung an die downstream-API aus. Gibt Statuscode, Header und Textkörper aus der nachgeschalteten Antwort zurück. Unterstützt Benutzer-OBO-, Nur-App- oder Agent-Identitätsmuster.

Path-Parameter

• serviceName – Konfigurierter nachgeschalteter API-Name.

Zusätzliche Abfrageparameter (zusätzlich zu /AuthorizationHeader Parametern)

Anforderung der Textweiterleitung

Der Text wird unverändert durchlaufen:

POST /DownstreamApi/Graph?optionsOverride.RelativePath=me/messages HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGc...
Content-Type: application/json

{ 
  "subject": "Hello", 
   "body": { "contentType": "Text", "content": "Hello world" } 
}

Antwort

{
  "statusCode": 200,
  "headers": {
    "content-type": "application/json"
  },
  "content": "{\"@odata.context\":\"...\",\"displayName\":\"...\"}"
}

Fehlerspiegelung /AuthorizationHeader und nachgeschaltete API-Fehlerstatuscodes.

/DownstreamApiUnauthenticated/{serviceName}

Identisch mit /DownstreamApi/{serviceName} dem, aber kein eingehendes Benutzertoken wird überprüft. Wird für Nur-App- oder autonome Agent-Vorgänge verwendet.

/healthz

Endpunkt für grundlegende Integritätssonden.

Antwort

Gesund (200):

HTTP/1.1 200 OK

Ungesund (503):

HTTP/1.1 503 Service Unavailable

/openapi/v1.json

Gibt die OpenAPI 3.0-Spezifikation zurück (nur Entwicklungsumgebung). Verwendung:

• Generieren von Clientcode
• Überprüfen von Anforderungen
• Ermitteln von Endpunkten

Häufige Fehlermuster

Ungültige Anforderung (400)

Fehlender Dienstname:

// 400 Bad Request - Missing service name
{ "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1", "title": "Bad Request", "status": 400, "detail": "Service name is required" }

// 400 Bad Request - Invalid agent combination
{ "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1", "title": "Bad Request", "status": 400, "detail": "AgentUsername and AgentUserId are mutually exclusive" }

// 401 Unauthorized - Invalid token
{ "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1", "title": "Unauthorized", "status": 401 }

// 403 Forbidden - Missing scope
{ "type": "https://tools.ietf.org/html/rfc7231#section-6.5.3", "title": "Forbidden", "status": 403, "detail": "The scope 'access_as_user' is required" }

// 404 Not Found - Service not configured
{ "type": "https://tools.ietf.org/html/rfc7231#section-6.5.4", "title": "Not Found", "status": 404, "detail": "Downstream API 'UnknownService' not configured" }

// 500 Internal Server Error - Token acquisition failure
{ "type": "https://tools.ietf.org/html/rfc7231#section-6.6.1", "title": "Internal Server Error", "status": 500, "detail": "Failed to acquire token for downstream API" }

MSAL-Fehlerbeispiel

{ "type": "https://tools.ietf.org/html/rfc7231#section-6.6.1", "title": "Internal Server Error", "status": 500, "detail": "MSAL.NetCore.invalid_grant: AADSTS50076: Due to a configuration change ...", "extensions": { "errorCode": "invalid_grant", "correlationId": "..." } }

Vollständige Außerkraftsetzungsreferenz

optionsOverride.Scopes=<scope>     # Repeatable
optionsOverride.RequestAppToken=<true|false>
optionsOverride.BaseUrl=<url>
optionsOverride.RelativePath=<path>
optionsOverride.HttpMethod=<method>
optionsOverride.AcquireTokenOptions.Tenant=<tenant-id>
optionsOverride.AcquireTokenOptions.AuthenticationScheme=<scheme>
optionsOverride.AcquireTokenOptions.CorrelationId=<guid>
optionsOverride.AcquireTokenOptions.PopPublicKey=<base64-key>
optionsOverride.AcquireTokenOptions.PopClaims=<json>
optionsOverride.CustomHeader.<Name>=<value>

AgentIdentity=<agent-client-id>
AgentUsername=<user-upn>            # Requires AgentIdentity
AgentUserId=<user-object-id>        # Requires AgentIdentity

Beispiele für Außerkraftsetzung

Außerkraftsetzen von Bereichen:

GET /AuthorizationHeader/Graph?optionsOverride.Scopes=User.Read&optionsOverride.Scopes=Mail.Read HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGc...

Ratenbegrenzung

Das Microsoft Entra ID Auth SDK (Sidecar) selbst erzwingt keine Ratenbeschränkungen. Effektive Grenzwerte stammen von:

1. Microsoft Entra ID Tokendiensteinschränkung (sollte nicht als SDK-Cachetoken geschehen)
2. Downstream-API-Grenzwerte
3. Effizienz des Tokencaches (reduziert das Kaufvolumen)

Bewährte Methoden

1. Bevorzugen Sie die Konfiguration gegenüber Ad-hoc-Außerkraftsetzungen.
2. Halten Sie Dienstnamen statisch und deklarativ.
3. Implementieren Sie Wiederholungsrichtlinien für vorübergehende Fehler (HTTP 500/503).
4. Überprüfen Sie die Agentparameter vor dem Aufrufen.
5. Protokollkorrelations-IDs für die Ablaufverfolgung über Dienste hinweg.
6. Überwachen der Tokenerwerbslatenz und Fehlerraten.
7. Verwenden Sie Integritätssonden in Orchestrierungsplattformen.

Verwandte Inhalte

• Konfigurationsreferenz
• Agentidentitäten
• Autorisierungsheader überprüfen
• Nachgeschaltete API aufrufen