Background-App braucht Zugriff? Client Credentials Flow verwenden

In Enterprise-Systemen kommunizieren Backend-Anwendungen oft ohne Benutzerinteraktion.

Dieses Muster wird verwendet, wenn:

• kein Benutzer beteiligt ist
• Systeme APIs direkt aufrufen
• die Authentifizierung über Microsoft Entra ID erfolgt

In diesem Beispiel:

• Dynamics 365 (D365) ist die aufrufende Anwendung
• Middleware API ist die Resource-Anwendung

Die Authentifizierung erfolgt mit dem OAuth 2.0 Client Credentials Flow. Die Autorisierung wird über App Roles gesteuert.

Middleware API App erstellen

Erstelle zuerst die Resource-Anwendung.

Gehe zu:

Entra ID > App registrations > New registration

Erstelle eine Anwendung:

Name: Middleware-API

Diese App Registration repräsentiert die API, die später Access Tokens empfängt und validiert.

API exponieren

Öffne innerhalb von Middleware-API:

Expose an API

Setze die Application ID URI:

api://<application-id>

Behalte das von Azure generierte Format bei, außer du hast einen klaren Namensstandard für deinen Tenant.

Diese ID wird später zur Audience für Tokens, die für die Middleware API ausgestellt werden.

App Role erstellen

Erstelle innerhalb von Middleware-API eine Application Role:

App roles > Create role

Beispiel:

Name: Middleware.Access
Value: middleware.access
Allowed member types: Applications

Das definiert anwendungsbasierte Autorisierung. Es ist kein benutzerbasierter Zugriff.

Die Middleware API kann später prüfen, ob das eingehende Token die erforderliche Rolle enthält.

D365 Client App und Secret erstellen

Erstelle jetzt die aufrufende Anwendung.

Gehe zu:

Entra ID > App registrations > New registration

Erstelle eine Anwendung:

Name: D365-Integration-App

Erstelle danach ein Client Secret:

Certificates & secrets > New client secret

Speichere den Secret-Wert sicher. Er wird benötigt, wenn sich die Client-Anwendung gegenüber Entra ID authentifiziert.

In echten Projekten sind Managed Identities oder zertifikatsbasierte Credentials oft besser. Wenn ein Client Secret verwendet wird, sollte es regelmäßig rotiert und niemals im Source Code gespeichert werden.

App Role über API Permissions zuweisen

Gehe zu:

App registrations > D365-Integration-App > API permissions

Wähle dann:

Add a permission

Wähle:

My APIs > Middleware-API > Application permissions > Middleware.Access

Klicke danach auf:

Grant admin consent

Damit erhält die D365 Client-Anwendung die Berechtigung, Tokens für die Middleware API mit der App Role middleware.access anzufordern.

Nachdem Admin Consent erteilt wurde, kann Entra ID Application Tokens mit dieser Rolle ausstellen.

Client Credentials Flow zur Laufzeit

Zur Laufzeit fordert D365 ein Token bei Entra ID an:

POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token

Request Body:

client_id=D365_CLIENT_ID
client_secret=SECRET
grant_type=client_credentials
scope=api://<application-id>/.default

Der .default Scope sagt Entra ID, dass ein Token mit den bereits gewährten Application Permissions der Client App ausgestellt werden soll.

Token-Ergebnis

Das Access Token enthält:

• App Role: middleware.access
• Audience: Middleware API
• keine Benutzeridentität

Dieser letzte Punkt ist wichtig: Das ist ein Application Token, kein delegiertes Benutzer-Token.

Enterprise-Hinweis

In echten Enterprise-Umgebungen gibt es meistens mehrere Stages:

• DEV
• TEST oder STAGE
• PROD

Wenn diese Umgebungen in verschiedenen Azure Subscriptions innerhalb desselben Entra ID Tenants getrennt sind, ist es Best Practice, separate App Registrations pro Umgebung zu erstellen.

Beispiel:

D365-Integration-App-DEV
D365-Integration-App-TEST
D365-Integration-App-PROD

Middleware-API-DEV
Middleware-API-TEST
Middleware-API-PROD

Das bietet:

• Isolation von Secrets und Credentials
• sichere Produktionsgrenzen
• unabhängige Deployments
• keine Token-Wiederverwendung zwischen Umgebungen
• klareres Auditing und Troubleshooting