App-Registrierung und OAuth-Leitfaden für die sichere Anwendungsintegration

Von Mirko Peters · 2026-05-04

Registrieren Sie Ihre App mit OAuth 2.0. Verstehen Sie den Autorisierungscodeflow für sicheren Zugriff, einen zentralen Bestandteil des Autorisierungscode-Grants von OAuth 2.0.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Seien wir ehrlich: Eine authentifizierungs- und App-Registrierung richtig umzusetzen, bedeutet nicht nur, cleveren Protokollen zu folgen. Es geht darum, dass Ihre Benutzer, Ihre Daten und Ihre Organisation sicher bleiben. Dieser Leitfaden entmystifiziert App-Registrierung und OAuth 2.0, damit Sie eine sichere, standardbasierte Authentifizierung mit Microsoft Entra ID (ehemals Azure AD) oder dem Anbieter Ihrer Wahl aufbauen können.

Wir schlüsseln die Schritte und Konzepte auf, die Sie benötigen, vom Verständnis dahinter, warum OAuth überhaupt existiert, bis zur praktischen Umsetzung für Web-, Mobile- oder SaaS-Apps. Dabei finden Sie klare Definitionen, praktische Hinweise und einen Fahrplan, der Ihre Integration auf Kurs hält und typische Fehler vermeidet, in die Entwickler beim Einstieg in OAuth häufig tappen. Ob Sie sich zum ersten Mal damit beschäftigen oder eine anspruchsvolle Unternehmenskonfiguration optimieren: Hier erhalten Sie das Wissen, um selbstbewusst zu bauen und die Kennungen zu verstehen, die Ihre Anwendung benötigt.

App-Registrierung und OAuth-Leitfaden – Definition

Die App-Registrierung ist der Prozess, bei dem eine Anwendungsidentität bei einem Identity Provider (etwa Azure AD, Google oder Auth0) angelegt und konfiguriert wird, damit die Anwendung Authentifizierung und Autorisierung sicher anfordern kann. Typischerweise umfasst sie die Vergabe einer Client-ID, eines Client-Geheimnisses oder Zertifikats, die Definition von Redirect-URIs, das Festlegen von Berechtigungen bzw. Scopes und die Konfiguration der zulässigen Grant-Typen.

8 überraschende Fakten zu App-Registrierung und OAuth-Leitfaden

• Client-Geheimnisse können über Protokolle abfließen: Viele Entwickler protokollieren beim Debuggen unbeabsichtigt Client-IDs und Geheimnisse. Dadurch sind die Anmeldedaten der App-Registrierung angreifbar, sofern die Protokollierungsrichtlinien nicht verschärft werden. Behandeln Sie Kennungen daher immer mit Sorgfalt.
• Redirect-URIs sind strenger als erwartet: OAuth-Anbieter verlangen häufig exakt übereinstimmende Redirect-URIs (einschließlich abschließender Schrägstriche und Schema). Schon kleine Unterschiede können Abläufe unterbrechen, die in der App-Registrierung korrekt aussehen.
• Public Clients benötigen keine Geheimnisse, brauchen aber trotzdem Schutz: Native Apps und Single-Page-Apps gelten als Public Clients ohne Client-Geheimnis. Dennoch müssen sie PKCE und sichere Redirect-Verfahren nutzen, um das Abfangen des Codes zu verhindern.
• Scopes garantieren standardmäßig kein Least Privilege: Bei der App-Registrierung fordern Standard-Scopes oder Zustimmungsdialoge oft weitreichende Berechtigungen an. Explizite Scope-Einschränkungen und schrittweise Zustimmung (Incremental Consent) sind unverzichtbar, um das Least-Privilege-Prinzip durchzusetzen.
• Token-Widerruf wird nicht überall unterstützt: Nicht alle Identity Provider berücksichtigen den Widerruf von Tokens oder bieten sofortige Abmeldung über alle Sitzungen hinweg. Die App-Registrierung muss daher Sitzungsverwaltung und Richtlinien für Refresh Tokens umfassen.
• Metadaten der App-Registrierung sind eine Angriffsfläche: Öffentlich sichtbare App-Namen, Logos und Redirect-URIs können Angreifern helfen, überzeugende Phishing- oder Open-Redirect-Angriffe vorzubereiten, wenn sie nicht sorgfältig verwaltet werden.
• Automatisierte Bereitstellung kann Berechtigungen falsch konfigurieren: CI/CD-Automatisierungen, die App-Registrierungen anlegen, vergeben oft zu weitreichende API-Berechtigungen oder registrieren erforderliche Redirect-URIs nicht. Das führt zu stillen Fehlern oder Sicherheitslücken.
• Die Zustimmungs-UX beeinflusst Sicherheitsentscheidungen: Benutzer und Administratoren erteilen häufig breite Zustimmungen, weil Zustimmungsdialoge unübersichtlich sind. Klare, minimale Zustimmungsabfragen in der App-Registrierung und im OAuth-Leitfaden verringern die übermäßige Zugriffsvergabe.

Grundlagen von OAuth 2.0 und Entra ID verstehen

OAuth 2.0 bildet das Rückgrat moderner Authentifizierungsabläufe. Es ermöglicht Apps, sicher auf Benutzerdaten und Ressourcen zuzugreifen, ohne jemals ein Kennwort zu sehen. Hier erhalten Sie einen Überblick über den OAuth-Prozess. Im Kern legt OAuth 2.0 fest, wie ein Benutzer (der „Ressourcenbesitzer“), eine App (der „Client“) und ein Identitätsanbieter (der „Autorisierungsserver“) zusammenarbeiten, damit Benutzer die Kontrolle über ihre Informationen behalten.

Was aber, wenn Sie Benutzer nicht nur für den Datenzugriff autorisieren, sondern sie authentifizieren möchten? Genau hier kommt OpenID Connect ins Spiel. Es legt eine sichere Identitäts- und Anmeldeebene über OAuth 2.0. Mit OpenID Connect können Anbieter wie Microsoft Entra ID und Google Ihre Apps überprüfen lassen, wer die Benutzer sind, und in einem einheitlichen Erlebnis zusätzliche Berechtigungen für weitere Ressourcen mit definiertem Umfang anfordern.

Begriffe wie „Client-ID“, „Autorisierungsendpunkt“ oder „Zugriffstoken“ wirken auf den ersten Blick schnell überwältigend. Sie beschreiben letztlich immer dasselbe: wer mit wem kommuniziert und was die jeweilige Seite tun darf. Microsoft Entra ID nutzt diese Protokolle, um Entwicklern eine standardbasierte Grundlage zu bieten, die von einfachen Geschäfts-Apps für einen einzelnen Mandanten bis hin zu großen Multi-Tenant-SaaS-Produkten reicht.

Wer diese Grundlagen versteht, baut auf bewährtem Fundament auf. Den passenden OAuth-Ablauf für Ihr Szenario zu wählen – etwa den Codeablauf für Webanwendungen oder den Gerätecodeablauf für Smart-TVs – sorgt für eine sichere, unkomplizierte Anmeldung, der Benutzer vertrauen und die Ihr Compliance-Team zu schätzen weiß.

App-Registrierung und OAuth-Leitfaden: Häufige Fehler bei OAuth 2.0 und Entra ID

Dieser Leitfaden zur App-Registrierung und OAuth beschreibt typische Fehler, die Teams bei der Implementierung von OAuth 2.0 mit Microsoft Entra ID (Azure AD) machen, und wie sich diese auf Sicherheit, Funktionalität und Benutzererfahrung auswirken.

• OAuth 2.0 mit Konzepten von OpenID Connect vermischen, etwa wenn ID-Token erwartet werden, obwohl nur Zugriffstoken ausgestellt werden.
• OAuth-Abläufe falsch einsetzen, etwa den impliziten Ablauf für moderne Apps verwenden, statt Authorization Code mit PKCE.

• Umleitungs-URIs falsch registrieren, etwa mit falschem Schema, abschließendem Schrägstrich oder localhost in der Produktivumgebung.
• Öffentliche Client-Einstellungen für vertrauliche Apps verwenden oder umgekehrt. Das führt zu Tokenfehlern oder legt Geheimnisse offen.
• Die richtigen API-Berechtigungen bzw. Bereiche nicht festlegen oder die Administratorzustimmung dort vergessen, wo sie erforderlich ist.

• Client-Geheimnisse in clientseitigen Code oder in öffentliche Repositories einbetten.
• Geheimnisse bzw. Zertifikate nicht regelmäßig rotieren oder abgelaufene Anmeldeinformationen nicht aus der App-Registrierung entfernen.
• Unnötig langlebige Geheimnisse verwenden, statt kurzlebige Zertifikate oder verwaltete Identitäten einzusetzen.

• Tokens nicht ordnungsgemäß validieren (Aussteller, Zielgruppe, Signatur, Nonce, Ablaufzeit).
• Zugriffs- oder Aktualisierungstoken unsicher speichern, etwa im lokalen Speicher des Browsers ohne Schutz.
• Tokeninhalte vertrauen, ohne die von Entra ID zurückgegebenen Bereiche bzw. Rollen zu prüfen.

• Annehmen, dass die Zustimmung eines Benutzers der App-Berechtigung entspricht, und nicht erkennen, dass manche Berechtigungen eine Administratorzustimmung erfordern.
• Zu viele Berechtigungen bzw. Bereiche anfordern. Das erhöht unnötig das Risiko und die Ablehnungsquote bei der Zustimmung.

• Die Rotation und Widerrufsrichtlinien für Aktualisierungstoken von Entra ID nicht berücksichtigen. Das führt zu unerwarteten Abmeldungen.
• Aktualisierungstoken in öffentlichen Clients ohne ausreichenden Schutz verwenden. Setzen Sie PKCE und passende Tokenlebensdauern ein.

• Multi-Tenant-Einstellungen für Apps, die mandantenübergreifend funktionieren sollen, nicht korrekt konfigurieren.
• Die falschen Endpunkte verwenden (mandantenspezifisch statt common) und dadurch Anmelde- oder Zustimmungsprobleme verursachen.

• Nicht testen, wie sich die App verhält, wenn Bedingter Zugriff, MFA oder Gerätekonformitätsrichtlinien erzwungen werden.
• Es ist nicht sicher, davon auszugehen, dass Token immer unter denselben Bedingungen ausgestellt werden. Richtlinien können blockieren oder zusätzliche Authentifizierungsschritte verlangen.

• Veraltete OAuth-Ababläufe oder Muster aus Azure AD v1 verwenden, statt die Empfehlungen der Microsoft Identity Platform (v2) umzusetzen.
• Community-Beispiele verwenden, ohne zu prüfen, ob sie sichere Verfahren umsetzen (PKCE, sichere Speicherung, korrekte Validierung).

• Authentifizierungsfehler oder Fehler bei der Token-Ausstellung nicht protokollieren, was die Diagnose erschwert.
• Rohe Fehlermeldungen direkt an Benutzer ausgeben, statt sie in verständliche, umsetzbare Hinweise zu übersetzen.

Nutzen Sie diesen Leitfaden zur App-Registrierung und zu OAuth, um Ihre Implementierung zu prüfen, die Best Practices der Microsoft Identity Platform zu befolgen und Sicherheits- und Betriebsrisiken bei der Integration von OAuth 2.0 mit Entra ID zu reduzieren.

Voraussetzungen für die App-Registrierung beim OAuth-Setup

Bevor Sie die Registrierungsmasken öffnen und den Namen Ihrer App in ein Portal eintragen, sollten Sie einige unverzichtbare Punkte prüfen. Zunächst benötigen Sie Zugriff auf das Microsoft Entra Admin Center Ihrer Organisation oder auf die entsprechende Konsole Ihres Identitätsanbieters. Hier gibt es keine Abkürzungen. Ohne die passenden Berechtigungen kommen Sie nicht einmal bis zum ersten Schritt.

Legen Sie außerdem fest, welche Art von Anwendung Sie entwickeln und welche Kennungen die Funktion benötigt. Handelt es sich um eine Webanwendung, eine Single-Page-Anwendung, eine mobile App oder vielleicht um einen automatisierten Dienst? Jeder Typ hat eigene Anforderungen an Authentifizierung und Autorisierung. Diese Entscheidung bestimmt die Sicherheitseinstellungen, die Sie später wählen.

Ebenso wichtig ist die Frage, wer Ihre Anwendung nutzen wird. Soll sie nur Personen in Ihrer eigenen Organisation zur Verfügung stehen (Single-Tenant)? Oder muss sie Benutzer aus anderen Unternehmen oder die breite Öffentlichkeit bedienen (Multi-Tenant)? Davon hängen Ihre Registrierungseinstellungen, die anwendbaren Benutzerverzeichnisse und der Zustimmungsablauf ab, den Ihre Benutzer sehen.

Erfassen Sie schließlich technische Details wie zulässige URLs für Anmelde-Umleitungen, die unterstützten Plattformen (iOS, Android, Windows?) und die Berechtigungen (oder „Bereiche“, englisch „Scopes“), die Ihre App anfordern soll. Wenn Sie diese Details vorab klären, sparen Sie bei der Einrichtung viel Zeit und vermeiden typische Stolpersteine wie ungültige URIs oder nicht zusammenpassende Kontotypen.

So registrieren Sie Ihre App bei Microsoft Entra ID

Die Registrierung Ihrer App in Microsoft Entra ID (früher Azure AD) bildet die Grundlage für alle Authentifizierungs- und API-Zugriffe. Der Prozess beginnt im Entra Admin Center. Dort legen Sie eine neue App-Registrierung an und geben Ihrer App eine eindeutige Identität (die sogenannte „Client-ID“) im Verzeichnis Ihrer Organisation.

Sie vergeben einen Namen für Ihre Anwendung und legen dann fest, wer sie verwenden darf: nur Ihre Organisation, mehrere Organisationen oder beliebige Microsoft-Konten. Dieser Schritt ist entscheidend, besonders bei SaaS- und B2B-Anwendungen, da er die Reichweite Ihrer App bestimmt und festlegt, wie die Mandantenzustimmung verwaltet wird.

Nach der Wahl der Zielgruppe konfigurieren Sie die Plattformdetails Ihrer App. Bei Webanwendungen fügen Sie eine Umleitungs-URI hinzu. Bei mobilen Apps oder Single-Page-Anwendungen sorgen plattformspezifische Einstellungen für reibungslose Anmeldungen. Das Entra-Portal führt Sie durch das Hinzufügen von Anmeldeinformationen wie Clientgeheimnissen oder Zertifikaten, mit denen Ihre App ihre Identität nachweist.

Mit der Registrierung richten Sie Ihre App an den OAuth-2.0-Standards aus und stellen sicher, dass der Authentifizierungsablauf sicher und konform bleibt. Ob Single-Tenant oder Multi-Tenant: Wenn Sie diese Einstellungen früh verstehen, legen Sie eine solide Grundlage für spätere Skalierung und Integrationen.

Die wichtigsten Vorteile der Registrierung Ihrer App bei Microsoft Entra ID

• Zentrales Identitätsmanagement: Verwalten Sie Authentifizierung, Autorisierung und Benutzeridentitäten für Ihre App über einen einzigen Entra-ID-Mandanten.
• Sichere OAuth-Abläufe: Nutzen Sie die integrierte Unterstützung für OAuth 2.0 und OpenID Connect, um sichere Anmeldungen, Token-Ausstellung und delegierten Zugriff umzusetzen.
• Single Sign-on (SSO): Ermöglichen Sie nahtloses SSO über Microsoft 365, Azure und weitere integrierte Dienste hinweg. So verbessern Sie das Benutzererlebnis und reduzieren Passwortabfragen.
• Granulare Berechtigungssteuerung: Definieren und verwalten Sie feingranulare API-Berechtigungen, Einwilligungsabläufe und Least-Privilege-Zugriff für delegierte und Anwendungsberechtigungen.
• Bedingter Zugriff und Sicherheitsrichtlinien: Erzwingen Sie MFA, Gerätekonformität, Standortbedingungen und risikobasierte Richtlinien, um den Zugriff auf Anwendungen und sensible Daten zu schützen.
• Verwaltete App-Geheimnisse und Anmeldeinformationen: Speichern und rotieren Sie Clientgeheimnisse, Zertifikate und Multi-Mandanten-Konfigurationen sicher und setzen Sie Lebenszyklusverfahren ein, damit die Integrität der Anwendungsnutzung erhalten bleibt.
• Integration mit Microsoft-Plattformdiensten: Greifen Sie mithilfe standardisierter Token und Einwilligungsmodelle auf Microsoft Graph, Azure-APIs, Teams und weitere Plattformfunktionen zu.
• Unterstützung für hybride und plattformübergreifende Apps: Authentifizieren Sie Benutzer in Web-, Mobil-, Desktop- und Dienst-zu-Dienst-Szenarien mit einheitlichen Identitätsprotokollen und stellen Sie sicher, dass jede Anwendung die richtigen Kennungen verwendet.
• Überwachung und Auditierung: Nutzen Sie Protokolle, Anmeldeberichte und Sicherheitserkenntnisse, um Anomalien zu erkennen, Vorfälle zu untersuchen und die Compliance aufrechtzuerhalten.
• Skalierbarkeit und Unternehmenstauglichkeit: Nutzen Sie die globale Infrastruktur von Entra ID, Multi-Mandanten-Optionen und Unternehmensfunktionen, um wachsende Benutzerzahlen und komplexe organisatorische Anforderungen zu unterstützen.
• Entwicklerwerkzeuge und Dokumentation: Nutzen Sie SDKs, Beispielcode und den Leitfaden zur App-Registrierung und zu OAuth, um die Implementierung zu beschleunigen und häufige Szenarien zu beheben.

Konfiguration von Redirect-URIs und Plattformeinstellungen für Entra ID-Apps

Die richtigen Redirect-URIs bei der App-Registrierung festzulegen wirkt einfach, ist aber ein entscheidender Sicherheitsschritt. Redirect-URIs teilen Entra ID mit, wohin Benutzer (zusammen mit ihren Tokens) nach einer erfolgreichen Anmeldung weitergeleitet werden sollen. Dabei setzt Entra strikte Regeln durch: keine Platzhalterdomänen, keine gefährlichen URI-Schemata und keine offenen Enden, die Angreifer ausnutzen könnten.

Wenn Sie eine Single-Page-Anwendung (SPA) entwickeln, verwenden Sie in der Regel eine HTTPS-URL, die auf Ihre App-Domäne zeigt, damit die Kommunikation für den Datenabruf der Anwendung sicher ist. Native Apps benötigen URI-Schemata, die an den Namen ihres App-Bundles oder Paketnamens gebunden sind. Dadurch wird verhindert, dass zufällige Apps auf demselben Gerät Tokens abfangen. Webanwendungen verwenden meist ihre Login-Callback-Endpunkte; jeder davon muss ausdrücklich aufgeführt werden.

Fehlkonfigurationen führen hier zu den klassischen Fehlern „Redirect URI mismatch“ und öffnen im schlimmsten Fall Angreifern die Tür, Tokens abzufangen. Nehmen Sie sich die Zeit, jede Plattform, auf der Ihre App laufen wird, samt den zugehörigen Redirect-URIs zu erfassen. So sorgen Sie für eine reibungslose Authentifizierung und ein gutes Gefühl.

Denken Sie daran, die Registrierung Ihrer App zu aktualisieren, wenn Sie Client-URLs ändern, Plattformen hinzufügen oder Umgebungen erweitern, etwa Test- und Produktivumgebungen. Diese URIs abzusichern und sauber zu halten, ist der erste Schritt, um Ihren Token-Ablauf lückenlos zu schützen.

OAuth-Ababläufe und grundlegendes Token-Management

OAuth 2.0 basiert auf einer Reihe von Autorisierungsabläufen für unterschiedliche Anwendungsfälle: Webanmeldungen, mobile Anmeldungen, Server-zu-Server-Aufrufe oder Apps, die ohne angemeldeten Benutzer laufen. Der beliebteste und sicherste dieser Abläufe ist der Autorisierungscode-Fluss. Er ist so konzipiert, dass sensible Tokens aus Browsern und mobilen Apps herausgehalten werden, und stellt Sicherheit an die erste Stelle.

Sobald sich ein Benutzer authentifiziert und die Einwilligung erteilt hat, erhält Ihre App einen kurzlebigen Code. Diesen muss sie am Token-Endpunkt gegen ein Zugriffs- und ein Aktualisierungstoken eintauschen. Diese Tokens gewähren zeitlich begrenzten Zugriff auf Daten. Läuft das Zugriffstoken ab, kann das Aktualisierungstoken ein neues Zugriffstoken anfordern, damit die Sitzung bestehen bleibt.

Token-Management bedeutet mehr, als Ablaufdaten zu verwalten. Es geht darum, Tokens jederzeit sicher zu halten. Dazu gehören sichere Kommunikation (etwa über HTTPS), das Vermeiden von Geheimnissen im clientseitigen Code und das Prinzip der minimalen Berechtigung bei der Angabe von Scopes.

Dieser Abschnitt bereitet Sie darauf vor, zu verstehen, wie OAuth die entscheidenden Abläufe zwischen Benutzern, Apps und Plattformen abwickelt und wie ein robustes Token-Management dauerhafte, sichere Workflows sowohl für Endbenutzer als auch für automatisierte Systeme unterstützt.

Implementierung des OAuth-Autorisierungscode-Flows

1. Autorisierung starten: Ihre App leitet den Benutzer an den Autorisierungsendpunkt von Entra ID weiter. Dabei übergibt sie Angaben wie Ihre Client-ID, die angeforderten Scopes und einen eindeutigen, zufälligen state-Parameter für den CSRF-Schutz.
2. Benutzer erteilt Berechtigung: Der Benutzer prüft den Einwilligungsbildschirm, auf dem klar angezeigt wird, welche Berechtigungen Ihre App benötigt, und genehmigt den Zugriff.
3. Autorisierungscode empfangen: Nach der Zustimmung leitet Entra ID zurück zu Ihrem angegebenen Umleitungs-URI und übergibt dabei einen temporären Autorisierungscode sowie den state-Wert, den Sie zu Beginn festgelegt haben.
4. Code gegen Token eintauschen: Ihr Backend sendet den Code sicher zusammen mit Ihren Client-Anmeldeinformationen (und gegebenenfalls dem PKCE-Code-Verifier) an den Token-Endpunkt von Entra. Nach erfolgreicher Prüfung erhalten Sie Zugriffstoken (und häufig Aktualisierungstoken).
5. Token für den Zugriff auf APIs verwenden: Ihre App hängt das Zugriffstoken nun an jede API-Anfrage an und weist so die Autorisierung im Namen des Benutzers nach. Zugriffstoken sind nur für kurze Zeit gültig, um das Risiko zu minimieren. Aktualisierungstoken dienen dazu, bei laufenden Sitzungen neue Zugriffstoken zu beziehen.

Wenn Sie diese Schritte in der richtigen Reihenfolge umsetzen, schließen Sie Sicherheitslücken und verhindern Angriffe wie das Abfangen von Codes oder den Missbrauch von Token. Das gilt besonders, wenn Sie mit öffentlichen Clients arbeiten oder sensible Daten verarbeiten.

Bewährte Methoden für den Umgang mit dem Ablauf von Zugriffs- und Aktualisierungstoken

1. Token sicher speichern: Verwenden Sie sichere, vom Betriebssystem bereitgestellte Speicherlösungen wie den Schlüsselbund unter iOS, den Keystore unter Android oder verschlüsselte Geheimnisverwaltungen auf dem Server. Hinterlegen Sie Token niemals fest im Code der App und geben Sie sie nicht in Protokollen aus.
2. Token-Lebensdauer beachten: Überwachen Sie den Ablaufwert (exp-Claim) jedes Tokens und aktualisieren Sie es rechtzeitig, bevor es abläuft, damit keine fehlgeschlagenen API-Anfragen und keine schlechte Benutzererfahrung entstehen.
3. Token-Rotation unterstützen: Verwenden Sie bei jeder Anfrage immer das neueste Aktualisierungstoken und verwerfen Sie wiederverwendete oder veraltete Token umgehend. So begrenzen Sie die Auswirkungen, falls ein Token kompromittiert wird.
4. Berechtigungen pro Token einschränken: Fordern Sie nur die Bereiche (Scopes) an, die Sie benötigen, und bevorzugen Sie Zugriffstoken mit kurzer Lebensdauer. Das reduziert den Schaden erheblich, falls ein Token abhandenkommt oder gestohlen wird.

OAuth-Implementierungen in unterschiedlichen Kontexten absichern

Eine OAuth-Integration richtig umzusetzen, bedeutet mehr, als nur Schritte abzuhaken. Es geht darum, Sicherheitsebenen aufzubauen, die zur Architektur Ihrer App und zu ihren Nutzungsmustern passen. Ob Ihre App im Browser, auf einem Smartphone oder rein in der Cloud läuft: Sie brauchen für jeden Kontext eine passende Authentifizierungsstrategie.

Verfahren wie PKCE (Proof Key for Code Exchange) sichern den Codefluss für öffentliche Clients ab und verhindern, dass Angreifer Codes abfangen und gegen Token tauschen. Für Apps in gesicherten Umgebungen sind dagegen Client-Geheimnisse und Zertifikate Ihre besten Werkzeuge, um Identitäten nachzuweisen und Vertrauen zu verwalten.

Ein sorgfältiger Umgang mit Token-Speicherung und ein genauer Blick auf die Berechtigungsstufen helfen, versehentliche Datenlecks zu vermeiden und den möglichen Schaden zu begrenzen, falls doch etwas schiefgeht. Wenn Sie die richtigen Sicherheitswerkzeuge einsetzen, also PKCE, Geheimnisse, Zertifikate und eine saubere Berechtigungsvergabe, verringern Sie Ihre Angriffsfläche deutlich und erhöhen die Chance auf einen reibungslosen, konformen Betrieb.

Im Folgenden finden Sie bewährte Strategien, mit denen sich gängige Bedrohungen abwehren lassen und Ihr OAuth-Setup für alle Arten von Apps und Umgebungen robust absichern lässt.

Wie PKCE die OAuth-Autorisierung in öffentlichen Clients schützt

PKCE (Proof Key for Code Exchange) ist beim Einsatz von OAuth in mobilen Apps und browserbasierten Apps unverzichtbar, also bei öffentlichen Clients, bei denen sich kein Geheimnis sicher speichern lässt. Wenn Sie den Autorisierungscodefluss starten, erzeugt Ihre App einen zufälligen „Code-Verifier“ und eine gehashte „Code-Challenge“. Diese Werte begleiten die Anfrage bis zur finalen Token-Anforderung. Selbst wenn ein Angreifer einen Autorisierungscode abfängt, kann er ihn ohne diesen geheimen Verifier nicht gegen ein Token eintauschen. Damit werden Angriffe durch das Abfangen von Codes in Microsoft Entra ID und vergleichbaren Plattformen nahezu unmöglich.

Client-Geheimnisse, Zertifikate und föderierte Anmeldeinformationen verwalten

• Client-Geheimnisse: Vertrauliche Apps, etwa vertrauenswürdige Backend-Dienste, verwenden sie, um ihre Identität am Token-Endpunkt nachzuweisen. Bewahren Sie Geheimnisse in sicheren Tresoren auf, rotieren Sie sie regelmäßig und stellen Sie sie niemals im clientseitigen App-Code bereit.
• Zertifikate: Für eine höhere Vertrauensstufe verwenden Sie X.509-Zertifikate statt einfacher Geheimnisse, um die Sicherheit der Bezeichner Ihrer Anwendung zu erhöhen. Zertifikate ermöglichen eine sicherere Prüfung über Paare aus öffentlichem und privatem Schlüssel und eignen sich ideal für regulierte Branchen oder Apps mit strengen Compliance-Anforderungen.
• Föderierte Anmeldeinformationen: Für Szenarien mit „eigener Identität mitbringen“ verwenden Sie föderierte Anmeldeinformationen, etwa die föderierte Identität von Microsoft Entra oder externe Anbieter. So ist eine Authentifizierung ohne direkten Umgang mit Geheimnissen möglich, was den Verwaltungsaufwand senkt.
• Pipeline-Handling: Fügen Sie in CI/CD-Workflows Geheimnisse und Zertifikate bei Bedarf ein und rotieren Sie sie. Hinterlegen Sie diese niemals fest im Quellcode. Automatisierte Ablaufwarnungen bieten eine zusätzliche Schutzebene.

Tokens schützen und unnötige Berechtigungen vermeiden

• Speichern Sie Tokens nur an sicheren Orten (Betriebssystem-Tresore, verschlüsselte Serverumgebungen), niemals in Speicherbereichen, auf die Benutzer zugreifen können.
• Übertragen Sie Tokens immer über HTTPS oder andere sichere Kanäle. Bei einfachem HTTP können Angreifer Tokens abfangen.
• Fordern Sie für jedes Token nur die minimal nötigen Berechtigungen („Scopes“) an. Bitten Sie niemals um mehr, als Ihre App benötigt.
• Prüfen Sie die Token-Nutzung und die Berechtigungszuweisungen regelmäßig, damit sich unbemerkt keine zusätzlichen Berechtigungen ansammeln.

Bewährte Methoden für OAuth in mobilen und nativen Anwendungen

Mobile und native Apps stellen heute besondere Herausforderungen dar: Geräte gehen verloren, Apps teilen sich Speicherplatz, und Benutzer erwarten eine schnelle, nahezu unsichtbare Anmeldung. Deshalb macht es einen entscheidenden Unterschied, die OAuth-Best-Practices für iOS, Android und Desktop zu befolgen, integrierte SDKs zu verwenden und bewährte Speichermechanismen einzusetzen.

Das passende SDK (etwa MSAL für Microsoft Entra ID) übernimmt einen Großteil der aufwendigen Arbeit: Es verwaltet Tokens, kümmert sich um die Aktualisierungslogik und integriert sich in den sicheren Speicher des Betriebssystems. Bei sensiblen Tokens ermittelt das SDK standardmäßig den sichersten Speicherort und berücksichtigt gerätespezifische bzw. betriebssystemspezifische Besonderheiten.

Achten Sie auch auf eine reibungslose Benutzerführung: Universal Links, Deep Links und Anmeldeabläufe im Systembrowser helfen Benutzern, die Anmeldung ohne Verwirrung und ohne Phishing-Risiko abzuschließen. Bei korrekter Konfiguration übergibt Ihre App den Benutzer an eine sichere, vertrauenswürdige Systemansicht und bringt ihn nach erfolgreicher Anmeldung sicher zurück in die App – ohne Pop-ups und ohne Token-Lecks.

Diese Vorgehensweisen dienen nicht nur dem Schutz der Tokens, sondern stärken auch das Vertrauen der Endbenutzer. Das erhöht die Akzeptanz und reduziert den Supportaufwand später deutlich.

Universal Links und native Authentifizierung der ersten Partei

Universal Links (unter iOS) und App-Schemas (unter Android) machen die Benutzerauthentifizierung deutlich sicherer. Durch vom Betriebssystem überprüfte Links, die an die Identität Ihrer App gebunden sind, verhindern Sie, dass fremde Apps Anmeldeumleitungen abfangen und Tokens abgreifen, die ihnen nicht gehören. Die native Authentifizierung nutzt vertrauenswürdige Systembrowser, sodass sich tatsächlich der echte Benutzer anmeldet. Phishing, das Ausspähen von Tokens und versehentliche Anmeldungen über unabhängige Apps werden so weitgehend ausgeschlossen. Zusammen bieten diese Werkzeuge ein nahtloses, sicheres Erlebnis, das gegen gängige Bedrohungen bei mobilem OAuth nahezu unangreifbar ist.

Fehlerbehebung bei OAuth-Fehlern und fortgeschrittene Szenarien

OAuth-Integrationen laufen beim ersten Versuch selten fehlerfrei – Fehler und ungewöhnliche Sonderfälle gehören einfach dazu. Häufig entstehen Probleme durch nicht übereinstimmende Umleitungs-URIs, abgelaufene Codes oder falsche Client-Geheimnisse. Solche Probleme können Anmeldeabläufe vollständig blockieren und die Nutzung der Anwendungen beeinträchtigen. Dieser Abschnitt zeigt Ihnen, wie Sie Fehlerantworten entschlüsseln, fehlgeschlagene Austauschvorgänge nachverfolgen und Probleme beheben, bevor sie den Helpdesk erreichen.

Über die Grundlagen hinaus erfordern einige Szenarien – etwa die Kommunikation zwischen Server und Server-Apps, die Anmeldung von IoT-Geräten oder der Bedarf an stärkeren Protokollgarantien – spezielle OAuth-Erweiterungen oder nicht interaktive Abläufe. Dienstkonten, gegenseitiges TLS (Mutual TLS) und Gerätecode-Abläufe sind genau für diese Anforderungen konzipiert.

Mit Hilfe zu häufigen Fehlern und fortgeschrittenen Anwendungsfällen sind Sie besser gerüstet, um robuste OAuth-Lösungen zu beheben, zu entwerfen und zu pflegen – auch dann, wenn Ihr App-Ökosystem komplexer wird.

Ob Sie einem hartnäckigen Fehler am Token-Endpunkt auf der Spur sind oder Ihre App auf den Alltag realer Umgebungen vorbereiten, in denen Geräte mit eingeschränkter Eingabe und headless-Dienste allgegenwärtig sind: Diese Erkenntnisse helfen Ihnen, Ihre Integrationen reibungslos und sicher zu halten.

OAuth-Fehlerantworten und Fehler beim Codeaustausch entschlüsseln

• Ungültige Umleitungs-URI: Tritt auf, wenn die Umleitung nicht mit der registrierten Liste übereinstimmt. Prüfen Sie Eingaben und Groß-/Kleinschreibung genau.
• Abgelaufener Autorisierungscode: Benutzer brauchen zu lange, oder Codes werden wiederverwendet. Verwenden Sie Codes immer nur einmal und zeitnah nach dem Erhalt.
• Nicht übereinstimmende Client-Anmeldeinformationen: Es wurde ein falsches Geheimnis oder Zertifikat übermittelt. Prüfen Sie die Anmeldeinformationen und rotieren Sie sie bei Bedarf.
• Ungültiger Scope oder ungültige Ressource: Die angeforderte API oder die Scopes sind nicht zulässig oder falsch geschrieben. Überprüfen Sie die Konfiguration und die App-Berechtigungen.

Dienstkonten, Geräte mit eingeschränkter Eingabe und OAuth-Erweiterungen

• Dienstkonten (Client-Credentials-Flow): Ermöglichen es Apps, sich ohne Benutzer zu authentifizieren. Ideal für Automatisierung und Server-zu-Server-Aufgaben.
• Gerätecode-Flow: Für Smart-TVs und IoT-Geräte. Der Benutzer wird auf einem anderen Gerät zur Anmeldung aufgefordert. Geeignet überall dort, wo kein Browser verfügbar ist.
• Mutual-TLS-Erweiterung: Verwendet Zertifikate sowohl für Server als auch für Client. Das erhöht die Sicherheit sensibler Integrationen und stellt sicher, dass die Anwendung starke Authentifizierungsmethoden nutzt.
• Dynamische Clientregistrierung: Automatisiert die Anbindung von Apps in großen SaaS- oder Multi-Tenant-Systemen und vereinfacht die Verwaltung von Anmeldeinformationen in großem Maßstab.

App-Registrierung und OAuth-Leitfaden für Entra ID

Vorteile

• Zentrale Identitätsverwaltung: Die Integration mit Microsoft Entra ID sorgt für einheitliche Benutzer- und App-Identitäten über alle Dienste hinweg.
• Starke Sicherheitskontrollen: Unterstützt OAuth 2.0, OpenID Connect, bedingten Zugriff und detaillierte Berechtigungen (Bereiche und Rollen).
• Branchenübliche Protokolle: Nutzt weit verbreitete OAuth/OIDC-Standards und vereinfacht so die Interoperabilität mit Tools und Bibliotheken von Drittanbietern.
• Detaillierte App-Konfiguration: Ermöglicht konfigurierbare Umleitungs-URIs, Zertifikate und Geheimnisse, API-Berechtigungen sowie Branding-Optionen für Apps.
• Granulares Einwilligungsmodell: Unterstützt delegierte und Anwendungsberechtigungen mit Administratoreinwilligungsprozessen, um übermäßig privilegierte Apps zu begrenzen.
• Enterprise-Funktionen: Unterstützt Multi-Tenant-Apps, B2B-Zusammenarbeit sowie die Integration mit Microsoft 365- und Azure-Diensten.
• Überwachung und Auditierung: Integrierte Protokolle, Anmeldungen und Prüfprotokolle für App-Registrierungen und OAuth-Abläufe unterstützen Compliance und Fehlerbehebung.
• Entwicklerwerkzeuge und SDKs: Umfangreiche SDKs der Microsoft Identity Platform, Dokumentation und Schnellstart-Beispiele erleichtern die Implementierung.

Nachteile

• Komplexität für Einsteiger: Konfigurations- und Berechtigungsmodelle (Umleitungs-URIs, Antwort-URLs, implizite vs. Autorisierungscode-Abläufe, Bereiche) können neue Entwickler verwirren.
• Steile Lernkurve bei Sicherheitsfunktionen: Bedingter Zugriff, verwaltete Identitäten und erweiterte Token-Einstellungen erfordern vertiefte Sicherheitskenntnisse, um sicher konfiguriert zu werden.
• Risiko wuchernder Berechtigungen: Unsachgemäße Einwilligungen oder weitreichende App-Berechtigungen können zu übermäßig privilegierten Anwendungen führen, wenn sie nicht regelmäßig überprüft werden.
• Besonderheiten bei der Token-Verwaltung: Der Umgang mit Aktualisierungstoken, Token-Lebensdauern und Token-Widerrufen unterscheidet sich je nach Plattform und kann zu Integrationsproblemen führen.
• Mandantengrenzen: Das Verhalten von Multi-Tenant-Apps und die Administratoreinwilligungsabfragen erhöhen den betrieblichen Aufwand bei mandantenübergreifenden Szenarien.
• Änderungen an Benutzeroberfläche und Begriffen: Microsoft aktualisiert die Entra-Oberfläche und deren Bezeichnungen (Azure AD → Entra ID) regelmäßig, was zu abweichender Dokumentation oder Verwirrung führen kann.
• Abhängigkeit vom Microsoft-Ökosystem: Die enge Kopplung an Entra-ID-Funktionen kann die Portierbarkeit zu Identitätsanbietern außerhalb von Microsoft ohne Umarbeitung einschränken.
• Gefahr von Fehlkonfigurationen: Falsche App-Registrierungseinstellungen (z. B. Umleitungs-URIs, Antwort-URLs, Einstellungen für den impliziten Ablauf) können Sicherheitslücken schaffen oder Authentifizierungsabläufe unterbrechen.

Nächste Schritte und wichtige Community-Ressourcen für eine erfolgreiche OAuth-Implementierung

Gut, OAuth ist eingerichtet und läuft, aber nehmen Sie den Fuß noch nicht vom Gas: Stellen Sie sicher, dass die Anwendung zum Abrufen von Token richtig konfiguriert ist. Die Grundlagen zu verdrahten ist erst der erste Schritt. Wenn Sie Ihre App wirklich hervorheben und Ihre Benutzer schützen möchten, ist jetzt der richtige Zeitpunkt, sich den Zusatzfunktionen zu widmen. Schauen Sie sich fortgeschrittene Client-Bibliotheken an, experimentieren Sie mit Microsoft Graph und entdecken Sie neue Identitätsfunktionen, die Ihre Integration stärker und für alle Beteiligten reibungsloser machen.

Sie müssen das auch nicht allein herausfinden. Die Dokumentation zu Microsoft Entra ID ist so umfangreich wie der Lake Michigan und enthält aktuelle Anleitungen, Codebeispiele und all die technischen Spezifikationen, die Sie wahrscheinlich griffbereit haben möchten. Prüfen Sie regelmäßig auf Aktualisierungen, besonders weil sich OAuth und die Standards für Cloud-Identitäten ständig weiterentwickeln.

Mit Ihrer App-Registrierung zufrieden? Gut. Schauen Sie sich nun an, wie andere kreative Lösungen umsetzen. Stöbern Sie in Entwicklerforen und offiziellen Diskussionsboards und werfen Sie auch einen Blick auf die GitHub-Repositories von Authentifizierungsbibliotheken. Wenn Sie an eine Wand stoßen, hat wahrscheinlich schon jemand Ihr genaues Problem gelöst oder sich zumindest lautstark darüber beschwert, sodass jemand geantwortet hat.

Wenn Sie gerne ausprobieren und durch Tun lernen, sehen Sie sich verfügbare kostenlose Testversionen, Testmandanten und Vorschau-Funktionen an. Damit können Sie gefahrlos experimentieren und herausfinden, was funktioniert, bevor Sie Änderungen für Ihre echten Benutzer einführen. Vergessen Sie außerdem nicht: OAuth und Sicherheit sind Gemeinschaftsarbeit. Teilen Sie Ihre Erfolge und Fragen, denn so bleibt das gesamte Ökosystem transparent und wächst stark, und alle können besser nachvollziehen, wie der Ablauf mit OAuth funktioniert.

App-Registrierung und OAuth-Leitfaden – Checkliste für Entra ID

• Anwendungstyp und Zugriffsmodell planen – Entscheiden Sie zwischen Single-Tenant, Multi-Tenant oder persönlichen Microsoft-Konten und legen Sie fest, ob es sich um eine SPA, Web-App, mobile App, Daemon- oder Dienst-App handelt.
• Registrieren Sie die Anwendung in Entra ID: Erstellen Sie eine neue App-Registrierung mit einem eindeutigen Namen und den unterstützten Kontotypen.
• Konfigurieren Sie Umleitungs-URIs: Hinterlegen Sie für jede Plattform die passenden Umleitungs- bzw. Callback-URIs (https, benutzerdefiniertes Schema, localhost für die Entwicklung).
• Legen Sie die Einstellungen der Anwendungsplattform fest: Aktivieren Sie die Optionen für SPA-, Web- sowie Mobil- & Desktopplattformen und konfigurieren Sie implizite Flows bzw. Grant-Flows bei Bedarf.
• Erstellen und verwalten Sie Clientgeheimnisse: Generieren Sie Clientgeheimnisse für vertrauliche Clients, achten Sie auf das Ablaufdatum und speichern Sie die Geheimnisse sicher (Key Vault).
• Verwenden Sie Zertifikate zur Authentifizierung: Laden Sie Zertifikate mit öffentlichem Schlüssel für produktive vertrauliche Clients hoch, anstatt langlebige Geheimnisse zu verwenden.
• Konfigurieren Sie API-Berechtigungen: Fügen Sie die Microsoft Graph- oder benutzerdefinierten API-Bereiche und -Berechtigungen hinzu, die die Anwendung benötigt.
• Erteilen Sie bei Bedarf die Administratoreinwilligung: Beantragen und dokumentieren Sie die Administratoreinwilligung für delegierte Berechtigungen, die eine mandantenweite Zustimmung erfordern.
• Definieren und veröffentlichen Sie benutzerdefinierte Bereiche (bei einer API): Fügen Sie unter „Eine API verfügbar machen“ Bereiche hinzu und legen Sie Bereichsnamen, Beschreibungen und Anzeigenamen für die Administratoreinwilligung fest.
• Richten Sie bei Bedarf App-Rollen ein: Definieren Sie Anwendungs- und delegierte Rollen für die rollenbasierte Zugriffssteuerung und weisen Sie diese Benutzern, Gruppen oder Client-Apps zu.
• Konfigurieren Sie CORS für SPAs, die APIs aufrufen: Fügen Sie erlaubte Ursprünge auf der API hinzu oder konfigurieren Sie CORS-Richtlinien im Gateway.
• Wählen Sie den OAuth-2.0-Flow: Wählen Sie je nach Szenario den Authorization Code Flow (mit PKCE für öffentliche Clients), den Client Credentials Flow für Daemon-Apps oder den Device Code Flow.
• Implementieren Sie PKCE für öffentliche Clients: Verlangen Sie Proof Key for Code Exchange für SPAs und native Apps, um das Abfangen von Autorisierungscodes zu verhindern.
• Validieren Sie Token korrekt: Prüfen Sie Aussteller, Zielgruppe, Signatur, Ablaufdatum und erforderliche Claims mithilfe der Microsoft-Identitätsbibliotheken oder einer JWT-Validierungslogik.
• Verwenden Sie die Microsoft Authentication Libraries (MSAL): Nutzen Sie MSAL für die Tokenanforderung, das Caching, die Aktualisierung und die sichere Verarbeitung auf allen Plattformen.
• Konfigurieren Sie bedingten Zugriff und MFA (bei Bedarf): Wenden Sie Richtlinien auf die App-Registrierung oder die Anmeldeabläufe der Benutzer an, um Sicherheitskontrollen durchzusetzen.
• Überwachen Sie Anmeldungen und Überwachungsprotokolle: Aktivieren Sie die Protokollierung und prüfen Sie Anmeldeereignisse, Zustimmungen und Administratorvorgänge in den Protokollen von Entra ID.
• Implementieren Sie das Least-Privilege-Prinzip: Fordern Sie nur die tatsächlich benötigten Berechtigungen an und bevorzugen Sie die schrittweise Einwilligung, um das Risiko zu minimieren.
• Rotieren Sie Geheimnisse und Zertifikate regelmäßig: Implementieren Sie eine automatisierte Rotation und Benachrichtigungen für ablaufende Anmeldeinformationen.
• Sichern Sie clientseitigen Code und Speicher: Speichern Sie keine Geheimnisse in Client-Apps, nutzen Sie sicheren Speicher und halten Sie sich an die bewährten Verfahren der jeweiligen Plattform.
• Testen Sie Anmelde- und Token-Flows in Entwicklungs- und Staging-Umgebungen: Prüfen Sie Authentifizierungsabläufe, Token-Lebensdauern, Aktualisierungslogik, Fehlerbehandlung und die Zustimmungsoberfläche.
• Erstellen Sie Dokumentationen für Benutzer und Administratoren: Nehmen Sie Zustimmungsschritte, erforderliche Berechtigungen und Hinweise zur Fehlerbehebung auf.
• Überprüfen und aktualisieren Sie App-Registrierungen regelmäßig: Kontrollieren Sie Berechtigungen, Rollen, Geheimnisse und Registrierungen auf veraltete oder ungenutzte Apps.
• Implementieren Sie Schutzmaßnahmen für Netzwerk und APIs: Ziehen Sie API Management, WAF, Ratenbegrenzung und Dienstendpunkte in Betracht, um Backend-APIs zu schützen.

Azure-Zugriffstoken verwenden OAuth-Authentifizierung

Was sind App-Registrierung & OAuth-Leitfaden und warum sind sie wichtig?

Ein App-Registrierung-&-OAuth-Leitfaden erklärt, wie Sie eine Clientanwendung bei einem Identitätsanbieter (zum Beispiel über Azure) registrieren und OAuth-2.0-Autorisierungsflows implementieren, damit Ihre Anwendung sicher Zugriff auf geschützte Ressourcen anfordern kann. Das ist unabhängig davon entscheidend, ob Sie Webanwendungen, Single-Page-Apps, Desktop-Apps oder Backends von Webservern entwickeln, denn die Anwendung benötigt eine App-ID bzw. Anwendungs-ID sowie eine Client-ID und ein Clientgeheimnis (bei vertraulichen Clients), um ein Zugriffstoken zu erhalten und gegebenenfalls ein ID-Token zu empfangen.

Wie registriere ich eine Azure-App und ermittle die Anwendungs-ID und App-ID?

Um eine Azure-App zu registrieren, öffnen Sie das Azure-Portal, erstellen Sie eine neue App-Registrierung, geben Sie einen Namen und Umleitungs-URIs an und notieren Sie die Client-ID (Anwendungs-ID), die in der Übersicht der Anwendung angezeigt wird. Wenn Ihre Anwendung ein vertraulicher Client ist (Webserver oder klassische Webanwendung), erstellen Sie ein Clientgeheimnis, das zusammen mit der Client-ID verwendet wird. Diese registrierte Anwendung dient der Autorisierung und dem Anfordern von Zugriffstoken für Microsoft-Dienste.

Welchen OAuth-2.0-Autorisierungsflow sollte ich für Single-Page-Apps verwenden?

Single-Page-Apps sollten den Autorisierungscodefluss mit PKCE (Proof Key for Code Exchange) statt des impliziten Flows verwenden. So stellen Sie sicher, dass die Anwendung Token sicher abruft. Der Codefluss mit PKCE ermöglicht es der Anwendung, den Code auf einem browserbasierten Client sicher gegen ein Zugriffstoken einzulösen. Single-Page-Apps können so OAuth nutzen, ohne Clientgeheimnisse im Browser offenzulegen.

Wie funktioniert die Autorisierungsanforderung, und welche Parameter sind erforderlich?

Eine Autorisierungsanforderung wird an den Autorisierungsendpunkt des Identitätsanbieters gesendet. Sie enthält in der Regel client_id (App-ID), response_type (zum Beispiel code), redirect_uri, scope und state. Bei Single-Page-Apps mit Codefluss und PKCE gehören außerdem code_challenge und code_challenge_method dazu. Der Benutzer meldet sich an und erteilt seine Zustimmung (OAuth-Zustimmung). Der Autorisierungsserver gibt anschließend einen Code an den Umleitungs-URI zurück, den die Anwendung gegen ein Zugriffstoken einlösen kann.

Wie programmiere ich den Austausch des Codes gegen ein Zugriffstoken?

Nach Erhalt des Autorisierungscodes sendet die Clientanwendung eine Anforderung an den Tokenendpunkt. Diese enthält den Code, client_id (bei vertraulichen Clients zusätzlich client_secret), redirect_uri und grant_type=authorization_code. Bei PKCE fügen Sie außerdem den code_verifier hinzu. Der Tokenendpunkt antwortet mit einem Zugriffstoken, einem ID-Token (sofern angefordert) und gegebenenfalls einem Aktualisierungstoken, mit dem Sie ein neues Zugriffstoken abrufen können, sobald das aktuelle abläuft.

Wie erhalte ich ein Zugriffstoken und verwende es für Aufrufe von APIs?

Ein Zugriffstoken erhalten Sie, indem Sie den gewählten OAuth-2.0-Autorisierungsflow abschließen und den Tokenendpunkt aufrufen. Anschließend übergeben Sie das Token im Authorization-Header mit dem Schema Bearer, wenn Sie Microsoft-Dienste oder andere APIs aufrufen (zum Beispiel Google Calendar oder eigene APIs). Überprüfen Sie Token auf dem Webserver bzw. auf der Ressourcenseite, damit sichergestellt ist, dass die Anfragen der Anwendung autorisiert sind.

Was tun Sie, wenn das Zugriffstoken abläuft, und wie erhalten Sie ein neues Aktualisierungstoken?

Wenn das Zugriffstoken abläuft, verwenden Sie das Aktualisierungstoken (sofern vorhanden), um über den Tokenendpunkt mit grant_type=refresh_token ein neues Zugriffstoken anzufordern. Manche Flows oder Anbieter stellen beim Aktualisieren ein neues Aktualisierungstoken aus, andere verwenden dasselbe weiter. Steht kein Aktualisierungstoken zur Verfügung (bei öffentlichen Clients oder kurzlebigen Flows), leiten Sie den Benutzer zurück in Ihre App, damit eine neue Autorisierungsanforderung ausgeführt wird.

Benötige ich separate App-Registrierungen für Webanwendungen und für mobile oder Desktop-Apps?

Häufig sind separate App-Registrierungen nötig, wenn sich die Anwendungstypen deutlich unterscheiden, etwa klassische Webserver, Single-Page-Apps und Desktop-Apps. Umleitungs-URIs, Clientgeheimnisse und zulässige Flows unterscheiden sich dann nämlich. Mit separaten App-Registrierungen konfigurieren Sie für jeden Anwendungstyp die passenden Autorisierungsflows und Umleitungs-URIs.

Was ist der Unterschied zwischen einer Client-App-Registrierung und einer Anwendung in einem Mandanten?

Eine Client-App-Registrierung ist der konkrete Registrierungseintrag beim Identitätsanbieter (die Azure-App), der Konfigurationen wie Umleitungs-URIs und Geheimnisse enthält. Eine Anwendung in einem Mandanten bedeutet, dass die Registrierung in einem bestimmten Azure-AD-Mandanten liegt und dort Rollen und Berechtigungen zugewiesen bekommen kann. Eine einzelne App-Registrierung kann je nach Anforderung mandantenübergreifend (Multitenant) oder auf einen Mandanten beschränkt (Single-Tenant) sein.

Wie fordere ich Zugriff auf Microsoft-Dienste an, und welche Berechtigungen werden benötigt?

Den Zugriff fordern Sie an, indem Sie in der Autorisierungsanforderung die Bereiche angeben, die Ihre Anwendung benötigt. Für Microsoft-Dienste konfigurieren Sie die API-Berechtigungen in der Azure-App-Registrierung. Anschließend bitten Sie die Benutzer um ihre Zustimmung (OAuth-Zustimmung) oder ein Administrator erteilt die Zustimmung mandantenweit. Die Anwendung fordert Bereiche wie User.Read oder eigene API-Bereiche im Rahmen der Anwendungsanforderungen an und verwendet das Zugriffstoken, um die Dienste aufzurufen.

Wie sichere ich Clientgeheimnisse und verhindere, dass Anmeldedaten in Single-Page-Apps offengelegt werden?

Single-Page-Apps sollten keine Clientgeheimnisse speichern, weil Code im Browser eingesehen werden kann. Verwenden Sie den Codefluss mit PKCE, damit die Anwendung ein Zugriffstoken ohne Clientgeheimnis sicher abrufen kann. Bei vertraulichen Apps (Webserver) speichern Sie Client-ID und Clientgeheimnis serverseitig, wo sie für Benutzer nicht sichtbar sind.

Welche Rolle spielt der Umleitungs-URI, und warum muss er mit der App-Registrierung übereinstimmen?

Die Redirect-URI ist die Adresse, an die der Identitätsanbieter die Autorisierungsantwort (Code oder Token) sendet. Sie muss mit der Redirect-URI übereinstimmen, die in der App-Registrierung hinterlegt ist, damit die Autorisierungsantwort nicht abgefangen werden kann. Verwenden Sie eine exakte Übereinstimmung oder die vom Anbieter definierten erlaubten Muster. Stimmen die Werte nicht überein, schlägt der Tokenaustausch fehl.

Wie erreiche ich, dass sich Benutzer authentifizieren und zusätzlich zu einem Zugriffstoken ein ID-Token erhalten?

Um ein ID-Token zu erhalten, fordern Sie den Bereich openid an und geben einen response_type an, der die Ausstellung eines ID-Tokens auslöst (Autorisierungscode-Flow mit openid). Das ID-Token enthält Identitätsansprüche über den authentifizierten Benutzer. Verwenden Sie das ID-Token, um den Benutzer in Ihrer Clientanwendung anzumelden, und das Zugriffstoken, um nachgelagerte APIs aufzurufen.

Welche spezifischen Autorisierungsabläufe gelten für klassische Webanwendungen im Vergleich zu Single-Page-Apps?

Klassische Webanwendungen (serverseitig) verwenden in der Regel den Autorisierungscode-Flow mit Clientanmeldeinformationen (Client-ID und Clientgeheimnis) und tauschen den Code auf dem Webserver aus. Single-Page-Apps nutzen den Autorisierungscode-Grant mit PKCE und ohne Clientgeheimnis. Desktop-Apps verwenden ebenfalls PKCE. Wählen Sie den Ablauf abhängig vom Anwendungstyp und davon, wo Geheimnisse sicher gespeichert werden können.

Kann eine App-Registrierung für mehrere Clientanwendungen verwendet werden, oder sollte ich für jede App eine eigene App-Registrierung erstellen?

Sie können eine App-Registrierung für mehrere Clientanwendungen nutzen, wenn diese dieselbe Konfiguration und Redirect-URIs haben. Bewährte Methoden empfehlen jedoch oft separate App-Registrierungen für unterschiedliche Anwendungen, um Berechtigungen, Redirect-URIs und den Lebenszyklus getrennt zu verwalten. Prüfen Sie, ob die Anwendung unterschiedliche Berechtigungsbereiche oder abweichende Verhaltensweisen bei der Administratorzustimmung benötigt.

Wie validiere ich Token in meinem Webserver oder meiner API?

Ihr Webserver oder Ihre API sollte die Signatur, den Aussteller, die Zielgruppe (App-ID bzw. Anwendungs-ID) und das Ablaufdatum des Zugriffstokens oder ID-Tokens prüfen. Verwenden Sie das Discovery-Dokument des Anbieters, um die Signaturschlüssel abzurufen, und folgen Sie den empfohlenen Validierungsbibliotheken für Ihre Plattform. Die Validierung stellt sicher, dass nur Anfragen von authentifizierten und autorisierten Anwendungen akzeptiert werden.

Wie beantrage ich ein Zugriffstoken für einen Backend-Dienst mithilfe von Clientanmeldeinformationen?

Registrieren Sie für Server-zu-Server-Szenarien eine Azure-App, weisen Sie ihr Anwendungsberechtigungen zu und verwenden Sie dann den Clientanmeldeinformationen-Flow: Senden Sie einen POST an den Tokenendpunkt mit grant_type=client_credentials, client_id, client_secret und scope bzw. resource. Der Tokenendpunkt gibt ein Zugriffstoken zurück, mit dem das Backend Microsoft-Dienste oder geschützte APIs aufrufen kann.

Wie behandle ich OAuth-Zustimmung und Administratorzustimmung für Mehrmandanten-Anwendungen?

Wenn Ihre App als Mehrmandanten-Anwendung registriert ist, können Benutzer aus anderen Mandanten während der Autorisierungsanfrage delegierten Berechtigungen zustimmen. Bei Berechtigungen, die eine Administratorzustimmung erfordern, muss ein Administrator die Zustimmung für seinen Mandanten erteilen. Stellen Sie Mandanten-Administratoren Anleitungen und eine Zustimmungs-URL zur Verfügung, damit sie die OAuth-Zustimmung im größeren Umfang erteilen können.

Welche Schritte zur Fehlerbehebung sollte ich durchführen, wenn meine Autorisierungsanfrage fehlschlägt?

Prüfen Sie, ob die App im Microsoft-Portal registriert ist, ob die Redirect-URI übereinstimmt, ob Client-ID und Clientgeheimnis korrekt sind, ob die Bereiche gültig sind und ob der Grant-Typ sowie gegebenenfalls die PKCE-Parameter korrekt sind. Prüfen Sie die Fehlermeldungen des Autorisierungs- bzw. Tokenendpunkts und sehen Sie in den Protokollen auf Client- und Serverseite nach. Stack Overflow und die Dokumentation des Anbieters helfen bei spezifischen Fehlercodes weiter.

Wie kann ich Drittanbieter-APIs wie Google Calendar in meine registrierte App integrieren?

Um Google Calendar oder andere Drittanbieter-APIs anzubinden, implementieren Sie die OAuth-2.0-Autorisierungsabläufe, die diese Anbieter verlangen. Ihre Anwendung muss die richtigen Bereiche für die Drittanbieter-API anfordern und die getrennten Lebenszyklen der Token berücksichtigen. Je nach Anbieter benötigen Sie separate Clientanwendungs-Registrierungen und müssen die Zugriffstoken für jeden Dienst gesondert abrufen.

Wann sollte ich den Device-Code-Flow oder andere spezielle Abläufe für bestimmte Geräte verwenden?

Verwenden Sie den Device-Code-Flow für eingabebeschränkte Geräte, auf denen kein Browser verfügbar ist. Dabei besucht der Benutzer eine Verifizierungs-URL auf einem anderen Gerät und meldet sich dort an. Er ist einer der speziellen Autorisierungsabläufe, die neben dem Autorisierungscode-Grant, dem Clientanmeldeinformationen-Flow und dem Aktualisierungstoken-Flow unterstützt werden, um verschiedene Anwendungstypen abzudecken.