Was passiert eigentlich, wenn Sie auf einer Power Pages-Website auf "Mit Microsoft anmelden" klicken? Dieser Leitfaden erklärt es mit einfachen Analogien und klaren Visualisierungen.
Die Kurzfassung: Ihr Portal bittet eine vertrauenswürdige Autorität (wie Microsoft), Ihre Identität zu überprüfen. Sie bestätigen es, und Sie sind drin. So einfach ist das.
Die drei Akteure
Bevor wir in die technischen Abläufe eintauchen, klären wir, wer beteiligt ist:
🧑 Sie (Der Benutzer)
Die Person, die sich anmelden möchte.
🏠 Power Pages (Ihr Portal)
Ihre Website. Sie muss wissen, wer Sie sind, bevor sie Sie hereinlässt.
🏛️ Identity Provider (Der Türsteher)
Das vertrauenswürdige Unternehmen, das Ausweise überprüft. Gängige Beispiele:
- Microsoft Entra External ID
- Okta
💭 Die zentrale Frage
Wie kann Ihr Portal darauf vertrauen, was Microsoft sagt?
Die Antwort: Digitale Signaturen. Wie ein fälschungssicheres Siegel auf einem Brief.
OAuth 2.0 / OpenID Connect Deep Dive
Gängige Identity Provider: Microsoft Entra External ID, Entra ID (Azure AD), Google, GitHub, Auth0, Okta (OIDC)
Protokoll-Ablauf: Authorization Code Flow mit PKCE (empfohlen) oder Hybrid Flow
🎭 Analogie aus dem echten Leben: Der Nachtclub mit Polizei-Verifizierung
Stellen Sie sich einen Nachtclub (Power Pages) vor, der keine eigenen Ausweise ausstellt. Stattdessen vertraut er der Polizeistation (Identity Provider), die Identität aller zu überprüfen.
- 1. Sie kommen am Club an und möchten hinein
- 2. Türsteher sagt: "Ich brauche einen Nachweis von der Polizeistation die Straße runter"
- 3. Sie gehen zur Polizeistation
- 4. Polizei überprüft Ihre Identität (prüft Ihren Pass) und gibt Ihnen ein gestempeltes Armband
- 5. Sie kehren mit dem Armband zum Club zurück
- 6. Türsteher prüft den Stempel (validiert, dass er echt ist) → "Sie dürfen rein!"
Warum das funktioniert: Der Club vertraut dem Stempel der Polizei. Die Polizei stempelt nur Armbänder für verifizierte Personen. Der Stempel kann nicht gefälscht werden (digitale Signatur). Das Armband läuft nach ein paar Stunden ab (Token-Ablauf).
🔧 Technischer Ablauf: Authorization Code Flow (Schritt für Schritt)
Phase 1: Benutzer initiiert Anmeldung
Schritt 1: Benutzer klickt auf "Mit Microsoft anmelden"-Button auf Power Pages
💡 Wie zum Nachtclub gehen
Phase 2: Autorisierungsanfrage
Schritt 2: Power Pages generiert eine Autorisierungsanfrage mit:
- •
client_id- Die ID Ihrer App - •
redirect_uri- Wohin nach der Anmeldung zurückgekehrt werden soll - •
scope- Welche Informationen Sie benötigen (openid, email, profile) - •
state- Zufallswert zur Verhinderung von CSRF-Angriffen - •
nonce- Zufallswert zur Verhinderung von Replay-Angriffen
💡 Wie der Türsteher, der eine Notiz schreibt: "Bitte verifizieren Sie diese Person und schicken Sie sie zurück"
Schritt 3: Browser leitet Benutzer zum Identity Provider weiter (z.B. Microsoft-Anmeldeseite)
💡 Wie zur Polizeistation gehen
Phase 3: Benutzer-Authentifizierung
Schritt 4: Benutzer gibt Benutzername und Passwort auf der Anmeldeseite des IdP ein
Schritt 5: IdP validiert die Anmeldedaten gegen seine Benutzerdatenbank
💡 Wie die Polizei, die Ihren Pass prüft
Phase 4: Authorization Code Austausch
Schritt 6: IdP generiert einen Authorization Code (kurzlebig, einmalig verwendbar)
Schritt 7: Browser leitet zurück zu Power Pages mit dem Code in der URL:
https://yoursite.powerappsportals.com/signin-oidc?code=abc123&state=xyz
💡 Wie eine temporäre Quittung von der Polizei bekommen - noch nicht der vollständige Ausweis
Schritt 8: Power Pages überprüft den state-Parameter (CSRF-Schutz)
Schritt 9: Power Pages macht eine Backend-Anfrage an den Token-Endpunkt des IdP:
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=abc123&
client_id=your-client-id&
client_secret=your-secret&
redirect_uri=https://yoursite.powerappsportals.com/signin-oidc💡 Wie der Club-Manager, der bei der Polizeistation anruft, um die Quittung zu verifizieren
Warum Backend? Das client_secret darf niemals dem Browser ausgesetzt werden!
Phase 5: Token-Validierung & Session-Erstellung
Schritt 10: IdP gibt Tokens zurück:
- • id_token (JWT) - Enthält Benutzeridentitäts-Claims
- • access_token - Für API-Aufrufe (optional in Power Pages)
- • refresh_token - Um neue Tokens ohne erneute Anmeldung zu erhalten (optional)
Schritt 11: Power Pages validiert das id_token:
- ✅ Signatur ist gültig (unter Verwendung des öffentlichen Schlüssels des IdP)
- ✅ Aussteller (
iss) stimmt mit erwartetem IdP überein - ✅ Zielgruppe (
aud) stimmt mit unserer client_id überein - ✅ Token ist nicht abgelaufen (
exp-Claim) - ✅ Nonce stimmt mit dem gesendeten überein
💡 Wie der Türsteher, der prüft, dass der Stempel echt und nicht abgelaufen ist
Schritt 12: Power Pages extrahiert Benutzer-Claims aus dem Token (E-Mail, Name, etc.)
Schritt 13: Power Pages erstellt oder aktualisiert Kontaktdatensatz in Dataverse
Schritt 14: Power Pages erstellt ein Session-Cookie
Schritt 15: Benutzer wird zur ursprünglich angeforderten Seite weitergeleitet
💡 Wie endlich mit Ihrem verifizierten Armband in den Club kommen
Phase 6: Nachfolgende Anfragen
Bei jedem Seitenaufruf: Power Pages prüft das Session-Cookie
Token abgelaufen? Refresh Token verwenden, um neue Tokens zu erhalten (falls konfiguriert)
Session abgelaufen? Benutzer muss sich erneut anmelden
🔐 Warum der Zwei-Schritt-Tanz? (Code → Tokens)
Das Problem: Wenn der IdP Tokens direkt in der Browser-URL (oder als POST an den Browser) senden würde, könnte bösartiges JavaScript auf der Seite sie stehlen.
Die Lösung: Der Authorization Code Flow trennt die Zuständigkeiten:
- Frontend: Browser sieht nur einen kurzlebigen, einmalig verwendbaren Authorization Code
- Backend: Power Pages Server tauscht den Code gegen Tokens unter Verwendung des Client Secret
- Ergebnis: Tokens berühren niemals den Browser, was Token-Diebstahl unmöglich macht
💡 Es ist, als würde man eine Quittung bei der Polizeistation bekommen, dann ruft der Club-Manager an, um zu verifizieren und die vollständigen Details privat zu erhalten.
📊 Visuelles Flussdiagramm
(client_id, redirect_uri, scope, state, nonce) PP->>Browser: 7. HTTP 302 Redirect to IdP Browser->>IdP: 8. GET /authorize?params end rect rgb(200, 255, 220) Note over User,IdP: User Authentication Phase IdP->>Browser: 9. Show login page User->>Browser: 10. Enter username/password Browser->>IdP: 11. POST credentials IdP->>IdP: 12. Validate credentials end rect rgb(255, 255, 200) Note over Browser,PP: Authorization Code Exchange IdP->>Browser: 13. HTTP 302 with code Browser->>PP: 14. GET /signin-oidc?code=xyz&state=abc PP->>PP: 15. Verify state parameter PP->>IdP: 16. POST /token
(code, client_id, client_secret) IdP->>IdP: 17. Validate code & client IdP->>PP: 18. Return id_token + access_token end rect rgb(220, 200, 255) Note over PP: Token Validation & Session Creation PP->>PP: 19. Validate id_token signature PP->>PP: 20. Check iss, aud, exp, nonce PP->>PP: 21. Extract user claims PP->>PP: 22. Create/update user in Dataverse PP->>PP: 23. Create session cookie end PP->>Browser: 24. Set-Cookie + Redirect to original page Browser->>PP: 25. Request original page with cookie PP->>Browser: 26. Return protected content Browser->>User: 27. Display page
💡 Diagramm-Legende: Die farbigen Boxen gruppieren zusammenhängende Schritte. Die Nummern entsprechen der schrittweisen Erklärung oben.
Erforderliche Parameter
Diese Parameter müssen konfiguriert werden, damit die Authentifizierung funktioniert:
| Parameter | Beschreibung | Beispielwert |
|---|---|---|
| Provider NameERFORDERLICH | Der Text, der auf dem Anmelde-Button angezeigt wird, den Benutzer auf der Anmeldeseite sehen | "Mit Firmenkonto anmelden" "Mit Microsoft anmelden" |
| AuthorityERFORDERLICH | Die Autorisierungs-Endpunkt-URL des Identity Providers. Dies teilt Power Pages mit, wohin Benutzer zur Authentifizierung weitergeleitet werden sollen. | https://{tenant}.ciamlogin.com/ (Entra External ID)https://login.microsoftonline.com/{tenant-id}/ (Entra ID)https://accounts.google.com/ (Google) |
| Client IDERFORDERLICH | Die Anwendungs-ID (Client-ID) aus Ihrer IdP-App-Registrierung. Diese identifiziert Ihre Power Pages-Site eindeutig beim Identity Provider. | 12345678-90ab-cdef-1234-567890abcdef |
| Redirect URLERFORDERLICH | Die Power Pages Callback-URL, an die der IdP Benutzer nach der Authentifizierung sendet. Wird automatisch von Power Pages generiert. Verwenden Sie immer die Kopieren-Schaltfläche - niemals manuell eingeben! | https://yoursite.powerappsportals.com/signin-oidchttps://customdomain.com/signin-oidc |
| Metadata AddressERFORDERLICH | Die URL des OpenID Connect Discovery-Dokuments. Diese URL enthält alle Endpunkte, unterstützten Funktionen und öffentlichen Schlüssel zur Token-Validierung des IdP. Power Pages ruft dieses Dokument automatisch ab, um sich selbst zu konfigurieren. | https://{tenant}.ciamlogin.com/.well-known/openid-configurationhttps://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration |
| ScopeERFORDERLICH | Leerzeichengetrennte Liste der anzufordernden OAuth-Scopes. openid ist obligatorisch für OpenID Connect. Fügen Sie email hinzu, um die E-Mail-Adresse des Benutzers zu erhalten, profile für Vor- und Nachname. |
openid email (minimal)openid email profile (empfohlen) |
| Response TypeERFORDERLICH | Der OAuth-Flow-Typ. code id_token (Hybrid Flow) wird aus Sicherheitsgründen empfohlen - es liefert sowohl einen Authorization Code (für den Backend-Token-Austausch) als auch ein ID-Token (für sofortige Benutzerinformationen). |
code id_token (empfohlen)codeid_token |
| Client SecretERFORDERLICH* | Das Client Secret aus Ihrer IdP-App-Registrierung. Erforderlich, wenn Response Type code enthält. Dieses Secret beweist dem IdP, dass die Token-Austausch-Anfrage von Ihrer autorisierten Power Pages-Site kommt. Halten Sie dieses Secret sicher! |
*Nur erforderlich, wenn Response Type code enthält |
| Response ModeERFORDERLICH | Wie der IdP die Authentifizierungsantwort zurückgibt. form_post wird empfohlen - es sendet Tokens per HTTP POST (sicherer als URL-Fragmente). |
form_post (empfohlen)queryfragment |
Optionale / Erweiterte Parameter
Diese Parameter bieten zusätzliche Kontrolle, sind aber für die Basisauthentifizierung nicht erforderlich:
| Parameter | Beschreibung | Standard / Anwendungsfall |
|---|---|---|
| External LogoutOPTIONAL | Föderierte Abmeldung aktivieren. Bei Ein meldet die Abmeldung von Power Pages den Benutzer auch vom IdP ab (und allen anderen Apps, die diesen IdP verwenden). Bei Aus erfolgt nur die Abmeldung von Power Pages - der Benutzer bleibt beim IdP angemeldet. | Aus (Standard) Einschalten für: Hochsicherheitsszenarien, die vollständige Abmeldung erfordern Ausschalten für: Benutzer, die in anderen Apps angemeldet bleiben müssen |
| Post Logout Redirect URLOPTIONAL | Wohin Benutzer nach der Abmeldung weitergeleitet werden. Muss in den erlaubten Abmelde-URLs des IdP konfiguriert sein. | https://yoursite.powerappsportals.com/ |
| RP Initiated LogoutOPTIONAL | Erlaubt der vertrauenden Partei (Power Pages), die Abmeldung beim IdP zu initiieren. Funktioniert nur, wenn External Logout eingeschaltet ist. | Aus (Standard) Erfordert: External Logout = Ein |
| Issuer FilterOPTIONAL | Wildcard-basierter Filter für Multi-Tenant-Szenarien. Verwenden Sie dies, wenn Sie Tokens von mehreren Azure AD-Tenants akzeptieren möchten. Das * passt auf jede Tenant-ID. |
https://sts.windows.net/*/Anwendungsfall: B2B-Portale, bei denen sich Benutzer verschiedener Unternehmen authentifizieren |
| Validate AudienceOPTIONAL | Zielgruppen-Validierung während der Token-Validierung aktivieren. Bei Ein überprüft Power Pages, ob der aud-Claim im Token mit einer Ihrer angegebenen Valid Audiences übereinstimmt. |
Aus (Standard) Produktionsempfehlung: Einschalten + Valid Audiences setzen |
| Valid AudiencesOPTIONAL | Kommagetrennte Liste erlaubter Zielgruppenwerte. Nur Tokens mit diesen Zielgruppen-Claims werden akzeptiert. Verhindert Token-Missbrauch über Anwendungen hinweg. | api://12345678-90ab-cdefapi://app1,api://app2Erfordert: Validate Audience = Ein |
| Validate IssuersOPTIONAL | Aussteller-Validierung während der Token-Validierung aktivieren. Bei Ein akzeptiert Power Pages nur Tokens von IdPs in Ihrer Valid Issuers-Liste. | Aus (Standard) Sicherheit: Verhindert Token-Replay von nicht autorisierten IdPs |
| Valid IssuersOPTIONAL | Kommagetrennte Liste erlaubter Aussteller-URLs. Nur Tokens von diesen Ausstellern werden akzeptiert. | https://sts.windows.net/{tenant1}/,https://sts.windows.net/{tenant2}/Erfordert: Validate Issuers = Ein |
| Registration Claims MappingOPTIONAL | Claims aus dem IdP-Token während der Benutzerregistrierung auf Dataverse-Kontaktfelder mappen. Format: contact_field=token_claim. Dies füllt automatisch Benutzerprofilfelder aus. |
firstname=given_name,lastname=family_nameUnterstützte Typen: Nur Text und Boolean |
| Login Claims MappingOPTIONAL | Claims aus dem IdP-Token bei jeder Anmeldung auf Dataverse-Kontaktfelder mappen. Verwenden Sie dies, um Kontaktdaten bei jeder Anmeldung mit IdP-Daten synchron zu halten. | firstname=given_name,lastname=family_nameTipp: Verwenden Sie das gleiche Mapping wie bei Registration für Konsistenz |
| Nonce LifetimeOPTIONAL | Wie lange (in Minuten) der Nonce-Wert gültig ist. Nonce verhindert Replay-Angriffe, indem sichergestellt wird, dass jede Authentifizierungsanfrage nur einmal verwendet werden kann. | 10 Minuten (Standard) Anpassen wenn: Benutzer in langsamen Netzwerken Timeouts erleben |
| Use Token LifetimeOPTIONAL | Power Pages Session-Lebensdauer an die IdP-Token-Ablaufzeit anpassen. Bei Ein wird das standardmäßige 8-Stunden-Session-Timeout überschrieben. Session endet, wenn Token abläuft (typischerweise 1 Stunde). | Aus (Standard = 8 Stunden) Einschalten für: Hochsicherheits-Portale, die häufige Re-Authentifizierung erfordern |
| Contact Mapping with EmailOPTIONAL | IdP-Identität automatisch mit Dataverse-Kontakt basierend auf E-Mail-Adressübereinstimmung verknüpfen. Ein: Wenn ein Kontakt mit übereinstimmender E-Mail existiert, IdP-Identität automatisch mit diesem Kontakt verknüpfen. Aus: Neuen Kontakt für jede neue IdP-Identität erstellen, auch wenn E-Mail mit bestehendem Kontakt übereinstimmt. |
Ein (Standard - empfohlen) Wichtig: Bei Aus kann derselbe Benutzer mehrere Kontakte erstellen, wenn er verschiedene IdPs verwendet |
💡 OAuth/OIDC Schnellstart
Für 90% der OAuth/OIDC-Szenarien benötigen Sie nur die Erforderlichen Parameter:
- App im IdP registrieren (Entra External ID, Google, etc.)
- Die Redirect URL aus Power Pages kopieren → als Redirect URI im IdP einfügen
- Client ID und Client Secret vom IdP erhalten
- Die Metadata Address finden (normalerweise in der IdP-App-Übersicht oder im Endpunkte-Bereich)
- Scope auf
openid emailsetzen (oderopenid email profile, wenn Sie Vor-/Nachname benötigen) - Response Type auf
code id_tokenund Response Mode aufform_postsetzen - Im Inkognito-Modus testen!
✅ OAuth/OIDC Do's und ❌ Don'ts
DO - OAuth Best Practices (Empfohlene Vorgehensweisen)
- ✅ Verwenden Sie
code id_tokenResponse Type - Hybrid Flow bietet beste Sicherheit und Benutzererfahrung - ✅ Fordern Sie immer
emailScope an - Erforderlich für Benutzeridentifikation und Kontakt-Mapping - ✅ Verwenden Sie die Kopieren-Schaltfläche für Redirect URL - Tippfehler in Redirect URLs verursachen 80% der OAuth-Fehler
- ✅ Überprüfen Sie, dass Metadata URL öffentlich zugänglich ist - Öffnen Sie sie im Browser ohne Authentifizierung
- ✅ Beginnen Sie mit minimalen Scopes -
openid emailist ausreichend, fügen Sieprofilenur bei Bedarf hinzu - ✅ Setzen Sie Client Secret Ablauf auf 6-12 Monate - Erzwingt Rotation ohne zu häufig zu sein
- ✅ Testen Sie Token Claims in jwt.io - Überprüfen Sie, dass E-Mail, Name, Gruppen wie erwartet ankommen
- ✅ Aktivieren Sie Diagnoseprotokollierung vor dem Testen - Power Pages → Einstellungen → Authentifizierung → Protokollierung aktivieren
- ✅ Testen Sie mit Nicht-Admin-Konten - Admin-Konten haben andere Token Claims
- ✅ Konfigurieren Sie Claims Mapping für Vorname/Nachname - Verbessert Benutzererfahrung auf der Profilseite
DON'T - OAuth Fallstricke
- ❌ Geben Sie Redirect URL nicht manuell ein - Ein falsches Zeichen = kryptischer "redirect_uri_mismatch" Fehler
- ❌ Vergessen Sie nicht den abschließenden Schrägstrich in Authority -
https://login.microsoftonline.com/{tenant-id}/(benötigt abschließenden /) - ❌ Teilen Sie Client Secrets nicht über mehrere Websites - Jede Power Pages-Website benötigt ihre eigene App-Registrierung
- ❌ Testen Sie nicht nur in Ihrem eigenen Browser - Testen Sie im Inkognito-Modus, verschiedenen Browsern, mobilen Geräten
- ❌ Verwenden Sie nicht Implicit Flow - Response Type
id_tokenallein ist veraltet, verwenden Siecode id_token - ❌ Fordern Sie keine unnötigen Scopes an - Mehr Scopes = mehr Zustimmungsaufforderungen für Benutzer = höhere Abbruchrate
- ❌ Ignorieren Sie Token-Ablauf nicht - Standard 1-Stunden-Token-Lebensdauer erfordert Session-Management-Strategie
- ❌ Vergessen Sie nicht Post Logout Redirect URL zu konfigurieren - Ohne diese sehen Benutzer die IdP-Abmeldeseite statt Ihrer Website
- ❌ Gehen Sie nicht davon aus, dass SSO = Single Sign-Out - SSO funktioniert, aber Single Sign-Out wird in Power Pages NICHT unterstützt
- ❌ Überspringen Sie nicht die Claims Mapping Validierung - Falsches Mapping = defekte Benutzerprofile
🚨 Top 5 OAuth/OIDC Konfigurationsfehler
1. Redirect URI Mismatch
Problem: URL in Power Pages stimmt nicht exakt mit URL in IdP-App-Registrierung überein (einschließlich abschließendem Schrägstrich, http vs. https, Groß-/Kleinschreibung)
Symptom: Fehler "redirect_uri_mismatch" oder "AADSTS50011: The redirect URI specified in the request does not match"
Lösung: Verwenden Sie die Kopieren-Schaltfläche in Power Pages, fügen Sie den EXAKTEN Wert in IdP ein. Überprüfen Sie abschließenden Schrägstrich, Protokoll (https) und Groß-/Kleinschreibung.
2. Fehlender oder falscher Scope
Problem: Scope enthält nicht openid (obligatorisch) oder email (erforderlich für Kontakt-Mapping)
Symptom: Authentifizierung funktioniert, aber Benutzer haben keine E-Mail-Adresse in Power Pages, Benachrichtigungen können nicht gesendet werden
Lösung: Setzen Sie Scope auf mindestens openid email. Fügen Sie profile hinzu, wenn Sie Vorname/Nachname benötigen.
3. Metadata URL nicht zugänglich
Problem: Metadata URL erfordert Authentifizierung oder befindet sich hinter Firewall/VPN
Symptom: "Unable to retrieve metadata" oder 404/401-Fehler während der Konfiguration
Lösung: Metadata URL muss öffentlich zugänglich sein. Testen Sie, indem Sie sie im Browser öffnen, ohne bei einem Konto angemeldet zu sein.
4. Abgelaufenes Client Secret
Problem: Client Secret ist abgelaufen (typischerweise nach 6-24 Monaten, abhängig von der Konfiguration)
Symptom: Authentifizierung funktionierte zuvor, stoppt plötzlich mit "invalid_client" oder "AADSTS7000222" Fehler
Lösung: Generieren Sie neues Client Secret im IdP, aktualisieren Sie es in Power Pages. Setzen Sie eine Kalender-Erinnerung 30 Tage vor dem nächsten Ablauf.
5. Falscher Response Mode
Problem: Verwendung von query oder fragment Response Mode mit code id_token Response Type
Symptom: Tokens erscheinen in der Browser-URL-Leiste (Sicherheitsrisiko) oder Fehler über Response Mode Mismatch
Lösung: Verwenden Sie immer form_post Response Mode - es ist die sicherste Option für Power Pages.
🎯 OAuth/OIDC Best Practices
Für Identity Provider Administratoren (Entra External ID, Google, Auth0)
App-Registrierungs-Setup
- Eine App-Registrierung pro Power Pages-Website - Isoliert Konfiguration, erleichtert Fehlerbehebung, bessere Sicherheit
- Verwenden Sie beschreibende App-Namen - "Power Pages Production Customer Portal" nicht "App1"
- Dokumentieren Sie alle Einstellungen - Screenshots der App-Registrierungseinstellungen erstellen, in Projektdokumentation speichern
- Konfigurieren Sie mehrere Besitzer - Verlassen Sie sich nicht auf eine einzelne Person für Secret-Rotation
Secret-Verwaltung
- Setzen Sie 6-Monats-Ablauf für Client Secrets - Balance zwischen Sicherheit (Rotation) und operativem Aufwand
- Verwenden Sie beschreibende Secret-Namen mit Ablaufdatum - "Prod Secret (Expires Dec 2025)" nicht "Secret 1"
- Erstellen Sie ZWEI Secrets mit gestaffeltem Ablauf - Ermöglicht Rotation ohne Ausfallzeit (Power Pages auf Secret 2 aktualisieren, dann Secret 1 rotieren)
- Setzen Sie Kalender-Erinnerungen 30 Tage vor Ablauf - Verhindert Notfall-"Authentifizierung ist ausgefallen"-Vorfälle
Claims & Token Konfiguration
- Fügen Sie immer E-Mail-Claim hinzu - Wesentlich für Power Pages Kontakt-Mapping
- Konfigurieren Sie optionale Claims für Profildaten - Aktivieren Sie given_name, family_name in Token-Konfiguration
- Testen Sie Tokens in jwt.io - Dekodieren Sie ID Tokens, um Claims zu überprüfen, bevor Sie in Power Pages testen
- Konfigurieren Sie Gruppen-Claims für Rollen-Mapping - Verwenden Sie Gruppen, um automatisch Power Pages-Rollen zuzuweisen
- Behalten Sie Token-Lebensdauer bei Standard 1 Stunde - Nicht verlängern, um Sicherheitsrisiken zu vermeiden
Für Power Pages Administratoren
Konfiguration & Testen
- Testen Sie immer im Inkognito-/Privat-Modus - Erfasst Cookie- und Cache-Probleme
- Aktivieren Sie Diagnoseprotokollierung VOR dem Testen - Protokolle zeigen exakte OAuth-Fehler mit Fehlercodes
- Testen Sie mit Nicht-Admin-Konten - Admin-Tokens haben andere Claims, nicht repräsentativ für Endbenutzer
- Testen Sie auf verschiedenen Geräten - Desktop Chrome, mobile Safari, Edge - OAuth verhält sich unterschiedlich
- Überprüfen Sie, dass E-Mail-Claim im Kontaktdatensatz ankommt - Kontaktdatensatz nach erster Anmeldung prüfen
Claims Mapping
- Konfigurieren Sie Registration Claims Mapping -
firstname=given_name,lastname=family_name - Verwenden Sie das gleiche Mapping für Login Claims Mapping - Hält Kontaktdaten bei jeder Anmeldung mit IdP synchron
- Mappen Sie keine Felder, die Benutzer nicht ändern können - Mapping von Berufsbezeichnung, wenn Benutzer sie nicht aktualisieren können, führt zu Verwirrung
- Testen Sie Claims Mapping mit echtem Benutzerkonto - Überprüfen Sie, dass gemappte Felder korrekt im Kontaktdatensatz erscheinen
Session-Verwaltung
- Verstehen Sie Standard-8-Stunden-Session - Power Pages Session != Token-Ablauf (Token läuft nach 1 Stunde ab, Session läuft weiter)
- Erwägen Sie Use Token Lifetime für Hochsicherheits-Portale - Erzwingt erneute Authentifizierung, wenn Token abläuft
- Testen Sie Session-Ablauf-Verhalten - Was passiert nach 8 Stunden? Erhält der Benutzer eine klare Fehlermeldung?
- Klären Sie Benutzer über IdP-Session vs. Power Pages-Session auf - Abmelden vom Portal meldet nicht vom IdP ab
Für Berater & Entwickler
Fehlerbehebungs-Workflow
- Schritt 1: Redirect URL überprüfen - 80% der OAuth-Probleme sind Redirect URL Mismatch
- Schritt 2: Metadata URL Erreichbarkeit prüfen - Im Browser öffnen, sollte JSON ohne Authentifizierung zurückgeben
- Schritt 3: Client ID und Secret überprüfen - Aus IdP kopieren und einfügen, nicht auf Gedächtnis verlassen
- Schritt 4: Scope-Konfiguration prüfen - Muss mindestens
openidenthalten - Schritt 5: Power Pages Diagnoseprotokolle prüfen - Nach spezifischen Fehlercodes suchen (AADSTS*, invalid_client, etc.)
- Schritt 6: Browser DevTools Network-Tab verwenden - OAuth-Flow beobachten: Autorisierungsanfrage → Redirect → Token-Austausch
Häufige Fehlercodes
- AADSTS50011 - Redirect URI mismatch → Exakte URL in IdP vs. Power Pages prüfen
- AADSTS7000222 - Invalid client secret → Neues Secret generieren, Power Pages aktualisieren
- AADSTS50105 - User not assigned to app → Benutzer zur App-Zuweisung in IdP hinzufügen
- invalid_request - Missing required parameter → Scope, Client ID, Response Type prüfen
- unauthorized_client - Client not authorized → App-Registrierungseinstellungen, Zustimmungsanforderungen prüfen
Projekt-Auslieferung
- Screenshot von JEDEM funktionierenden Konfigurationsbildschirm - Client ID, Authority, Scopes, Claims Mapping
- Client Secret Rotationsprozess dokumentieren - Wer macht es, wie oft, was ist der Prozess
- Fehler-Runbook erstellen - Während des Testens aufgetretene Fehler mit Lösungen dokumentieren
- Benutzerdokumentation bereitstellen - Erklären, warum Benutzer zustimmen müssen, wie Abmeldung funktioniert, Session-Timeout
Single Sign-On (SSO) mit OAuth/OpenID Connect
Schnelle Antwort: Ja! OAuth 2.0 und OpenID Connect ermöglichen SSO über mehrere Anwendungen hinweg.
🔑 Wie SSO funktioniert
🎭 Die Konzert-Armband-Analogie
Stellen Sie sich ein Musikfestival mit mehreren Bühnen (Anwendungen) vor:
- Eingangstor prüft Ihr Ticket und gibt Ihnen ein Armband
- Bühne 1 (App 1) sieht Ihr Armband → "Sie sind drin!"
- Bühne 2 (App 2) sieht dasselbe Armband → "Sie sind auch hier drin!"
- Kein erneutes Zeigen des Tickets an jeder Bühne erforderlich
Dieses Armband = Ihr Access Token vom Identity Provider.
✅ Was Power Pages unterstützt
- ✅ Single Sign-In - Einmal anmelden, auf mehrere Power Pages-Sites zugreifen (wenn sie denselben IdP verwenden)
- ✅ Anwendungsübergreifendes SSO - Funktioniert mit anderen Apps, die denselben Identity Provider verwenden
- ✅ Front-Channel Sign-Out - Meldet Sie sowohl von Power Pages ALS AUCH vom IdP ab
❌ Was Power Pages nicht unterstützt
- ❌ Single Sign-Out - Das Abmelden von einer App meldet Sie nicht automatisch von allen Apps ab
- ❌ Provider-übergreifendes SSO - Sitzungen können nicht zwischen Google- und Microsoft-Anmeldungen geteilt werden
🎯 Reale SSO-Szenarien
Szenario 1: Mitarbeiterportal + Intranet
Setup: Beide verwenden Microsoft Entra External ID
Ergebnis:
- ✅ Mitarbeiter meldet sich bei SharePoint an → Erhält Token von Entra External ID
- ✅ Mitarbeiter besucht Power Pages-Portal → Derselbe Token funktioniert!
- ✅ Keine zweite Anmeldung erforderlich ✅
Szenario 2: Kundenportal + Support-App
Setup: Beide verwenden Okta
Ergebnis:
- ✅ Kunde meldet sich bei Support-App an → Erhält Okta-Token
- ✅ Kunde klickt auf Link zum Power Pages-Portal → Automatisch angemeldet!
- ✅ Nahtlose Erfahrung ✅
⚠️ Was bricht SSO?
- ❌ Unterschiedliche Identity Provider - Portal verwendet Google, App verwendet Microsoft (Sitzungen werden nicht geteilt)
- ❌ Token abgelaufen - Token halten typischerweise 1 Stunde, dann müssen Sie sich erneut authentifizieren
- ❌ Unterschiedliche Domains - Cookies überschreiten keine Domain-Grenzen (verwenden Sie wenn möglich dieselbe Parent-Domain)
- ❌ Inkognito-/Privater Modus - Keine Cookies = kein SSO
🔧 SSO einrichten
Schritt 1: Überall denselben Identity Provider verwenden
- • Alle Apps → Microsoft Entra External ID, ODER
- • Alle Apps → Okta, ODER
- • Alle Apps → Google
Schritt 2: Apps im IdP konfigurieren
- • Jede App registrieren (Power Pages, SharePoint, Custom Apps)
- • Denselben Tenant/Organisation verwenden
- • Korrekte Redirect-URLs für jede App konfigurieren
Schritt 3: Den Flow testen
- • Bei App 1 anmelden → Token erhalten
- • App 2 im selben Browser öffnen → Sollte automatisch anmelden
- • Prüfen: Keine zweite Passwort-Abfrage = SSO funktioniert! ✅
📊 SSO Token-Lebensdauer
| Token-Typ | Typische Lebensdauer | Was danach passiert |
|---|---|---|
| ID Token | 1 Stunde | Muss erneuert werden (normalerweise stillschweigend) |
| Access Token | 1 Stunde | Muss mit Refresh Token erneuert werden |
| Refresh Token | 90 Tage (Microsoft) | Erneute Anmeldung erforderlich |
| Power Pages Session | 8 Stunden (konfigurierbar) | Weiterleitung zur Anmeldeseite |
💡 Pro-Tipp: Stillschweigende Token-Erneuerung
OAuth/OpenID Connect-Provider können Token stillschweigend im Hintergrund erneuern, indem sie Refresh Tokens verwenden. Das bedeutet:
- ✅ Die Sitzung des Benutzers bleibt aktiv ohne erneute Anmeldung
- ✅ Geschieht automatisch bevor der Token abläuft
- ✅ Der Benutzer bemerkt nichts ✅
Power Pages macht dies automatisch. Sie müssen nichts Besonderes konfigurieren.
🚫 Wenn SSO nicht funktioniert
Problem: "Ich habe mich bei App A angemeldet, muss mich aber trotzdem bei Power Pages anmelden"
Checkliste:
- ☐ Derselbe Identity Provider? (Beide müssen Entra External ID verwenden, nicht ein Entra + ein Google)
- ☐ Derselbe Tenant? (Beide müssen im selben Entra External ID-Tenant sein)
- ☐ Derselbe Browser? (SSO funktioniert nicht über verschiedene Browser hinweg)
- ☐ Cookies aktiviert? (SSO benötigt Cookies)
- ☐ Token noch gültig? (Prüfen, ob abgelaufen)
🎯 SSO Best Practices
- ✅ Halten Sie es einfach - Ein IdP für alle Apps (keine Mischung aus Google + Microsoft + Okta)
- ✅ Kommunizieren Sie Sitzungslimits - Informieren Sie Benutzer: "Sitzung läuft in 8 Stunden ab"
- ✅ Implementieren Sie "Angemeldet bleiben" - Längerer Refresh Token = weniger erneute Anmeldungen
- ✅ Testen Sie über Apps hinweg - Stellen Sie sicher, dass SSO vor dem Launch tatsächlich funktioniert
- ✅ Dokumentieren Sie den Flow - Damit der Support weiß, was zu erwarten ist
SAML 2.0 Deep Dive
Häufige Identity Provider: Okta, Microsoft Entra ID (Enterprise Apps), Azure AD B2C (mit Custom Policies), Ping Identity, OneLogin, Shibboleth
Protokoll-Flow: SP-initiierter SAML-Flow (Power Pages leitet Benutzer zur Authentifizierung zum IdP weiter)
🎭 Reale Analogie: Das Botschafts-Visa-System
Stellen Sie sich vor, Sie möchten in ein fremdes Land (Power Pages) einreisen, das ein Visum erfordert. Sie können nicht einfach auftauchen - Sie benötigen einen Nachweis von der Botschaft Ihres Heimatlandes (Identity Provider), dass Sie berechtigt sind.
- 1. Sie kommen an der Grenze an (Power Pages-Anmeldeseite)
- 2. Grenzbeamter sagt: "Sie benötigen ein Visum von Ihrer Botschaft" und gibt Ihnen ein offizielles Formular (SAML Request)
- 3. Sie bringen das Formular zu Ihrer Botschaft (IdP-Anmeldeseite)
- 4. Botschaftspersonal überprüft Ihre Identität (prüft Ihren Reisepass, stellt Sicherheitsfragen)
- 5. Botschaft stempelt Ihr Visums-Antragsformular (SAML Assertion) mit einem offiziellen Siegel
- 6. Sie kehren mit dem gestempelten Formular zur Grenze zurück
- 7. Grenzbeamter überprüft das Botschaftssiegel (XML-Signatur-Validierung), prüft ob es authentisch ist → "Willkommen!"
Warum dies funktioniert: Der Grenzbeamte vertraut dem Botschaftssiegel (beide haben sich vorher auf Sicherheitszertifikate geeinigt). Das Botschaftssiegel ist manipulationssicher (digitale XML-Signatur). Das Visum hat eine Ablaufzeit (NotOnOrAfter). Das Visum gilt für diese spezifische Person (NameID stimmt überein).
🔧 Technischer Flow: SP-initiiertes SAML 2.0 (Schritt für Schritt)
Phase 1: Benutzer initiiert Anmeldung (Service Provider Initiated)
Schritt 1: Benutzer klickt auf "Mit Okta anmelden" (oder Ihrem SAML-Provider) in Power Pages
💡 Wie das Ankommen am Grenzkontrollpunkt
Phase 2: SAML Authentication Request (AuthnRequest)
Schritt 2: Power Pages generiert einen SAML AuthnRequest (XML-Dokument) mit folgendem Inhalt:
- •
Issuer- Service Provider Realm (Ihre Site-Kennung) - •
AssertionConsumerServiceURL- Wohin die Antwort gesendet werden soll - •
ID- Eindeutige Request-ID (verhindert Replay-Angriffe) - •
IssueInstant- Zeitstempel der Request-Erstellung
Beispiel SAML Request:
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_abcd1234"
Version="2.0"
IssueInstant="2025-11-06T10:30:00Z"
Destination="https://idp.example.com/saml/sso"
AssertionConsumerServiceURL="https://yoursite.powerappsportals.com/signin-saml2">
<saml:Issuer>https://yoursite.powerappsportals.com/</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
</samlp:AuthnRequest>💡 Wie der Grenzbeamte, der Ihnen ein offizielles Formular gibt, das Sie zur Botschaft bringen sollen
Schritt 3: Power Pages kodiert den XML-Request (Base64), komprimiert ihn optional (Deflate) und leitet den Browser zum IdP weiter:
https://idp.example.com/saml/sso?SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdC...
💡 Wie der Weg zur Botschaft mit dem Formular
Phase 3: Benutzer-Authentifizierung beim IdP
Schritt 4: IdP dekodiert und validiert den SAML Request
- ✅ Prüft, ob Issuer ein bekannter Service Provider ist
- ✅ Validiert, dass IssueInstant nicht zu alt ist
- ✅ Prüft, ob AssertionConsumerServiceURL registriert ist
Schritt 5: IdP zeigt dem Benutzer die Anmeldeseite
Schritt 6: Benutzer gibt Anmeldedaten ein (Benutzername/Passwort, MFA, etc.)
Schritt 7: IdP validiert die Anmeldedaten
💡 Wie das Botschaftspersonal, das Ihren Reisepass prüft und Sicherheitsfragen stellt
Phase 4: SAML Response (Assertion)-Generierung
Schritt 8: IdP erstellt eine SAML Assertion (XML) mit folgendem Inhalt:
- •
Issuer- EntityID des IdP - •
Subject/NameID- Eindeutige Benutzerkennung (E-Mail, UPN, etc.) - •
Conditions- Audience (muss Service Provider Realm entsprechen), NotBefore, NotOnOrAfter-Zeitstempel - •
AttributeStatement- Benutzer-Claims (E-Mail, Vorname, Nachname, Rollen) - •
AuthnStatement- Wann/wie sich der Benutzer authentifiziert hat
Beispiel SAML Assertion:
<saml:Assertion ID="_xyz5678" IssueInstant="2025-11-06T10:31:00Z">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="email">john.doe@company.com</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore="2025-11-06T10:30:00Z" NotOnOrAfter="2025-11-06T11:31:00Z">
<saml:AudienceRestriction>
<saml:Audience>https://yoursite.powerappsportals.com/</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AttributeStatement>
<saml:Attribute Name="email"><saml:AttributeValue>john.doe@company.com</saml:AttributeValue></saml:Attribute>
<saml:Attribute Name="firstname"><saml:AttributeValue>John</saml:AttributeValue></saml:Attribute>
</saml:AttributeStatement>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
</saml:Assertion>Schritt 9: IdP signiert die XML-Assertion mit seinem privaten Schlüssel (X.509-Zertifikat)
💡 Wie die Botschaft, die das Visums-Formular stempelt und versiegelt
Phase 5: POST Assertion zurück zum Service Provider
Schritt 10: IdP Base64-kodiert die signierte SAML Response
Schritt 11: IdP sendet ein sich automatisch absendendes HTML-Formular an den Browser (HTTP POST Binding):
<form method="POST" action="https://yoursite.powerappsportals.com/signin-saml2">
<input type="hidden" name="SAMLResponse" value="PD94bWwgdmVyc2lvbj0iMS4w..." />
<input type="submit" value="Continue" />
</form>
<script>document.forms[0].submit();</script>Schritt 12: Browser sendet automatisch POST an die Power Pages ACS-URL
💡 Wie die Rückkehr zur Grenze mit dem gestempelten Visum
Phase 6: Assertion-Validierung & Session-Erstellung
Schritt 13: Power Pages dekodiert die SAML Response
Schritt 14: Power Pages validiert die Assertion:
- ✅ Signatur gültig: Verwendet den öffentlichen Schlüssel des IdP (aus Metadata), um die XML-Signatur zu verifizieren
- ✅ Issuer stimmt überein: Assertion Issuer = Authentication Type (entityID)
- ✅ Audience stimmt überein: Audience = Service Provider Realm
- ✅ Nicht abgelaufen: Aktuelle Zeit zwischen NotBefore und NotOnOrAfter
- ✅ Nicht wiederholt verwendet: Assertion-ID wurde noch nicht verwendet (im Cache gespeichert)
💡 Wie der Grenzbeamte prüft: Botschaftssiegel authentisch? Visum für dieses Land? Nicht abgelaufen? Noch nicht verwendet?
Schritt 15: Benutzer-Attribute aus AttributeStatement extrahieren (E-Mail, Name, etc.)
Schritt 16: Kontakt-Datensatz in Dataverse mit NameID und Attributen erstellen oder aktualisieren
Schritt 17: Power Pages Session-Cookie erstellen
Schritt 18: Benutzer zur ursprünglich angeforderten Seite weiterleiten
💡 Wie schließlich die Erlaubnis zu erhalten, die Grenze zu überqueren
🔐 Wichtige SAML-Unterschiede zu OAuth/OIDC
1. XML statt JSON: SAML verwendet ausführliche XML-Dokumente. OAuth/OIDC verwendet kompakte JSON-Token.
2. Signaturen auf XML: SAML signiert die gesamte XML-Assertion. OAuth signiert JWT-Token mit einfacherer Base64-Kodierung.
3. Kein Backend-Token-Austausch: SAML-Assertion wird direkt per POST an den Browser gesendet (aber sie ist signiert, daher trotzdem sicher). OAuth hat einen Backend Code-for-Tokens-Austausch.
4. Zertifikat-basiertes Vertrauen: SAML erfordert den vorherigen Austausch von X.509-Zertifikaten. OAuth verwendet Metadata Discovery-URLs.
5. Enterprise-fokussiert: SAML ist älter (2005) und verbreitet in Enterprise/B2B-Szenarien. OAuth/OIDC ist neuer (2012/2014) und moderner.
📊 Visuelles Flow-Diagramm
(Service Provider) participant IdP as Identity Provider
(Okta/Entra ID) User->>Browser: 1. Navigate to portal Browser->>PP: 2. Request protected page PP->>Browser: 3. Redirect to login page rect rgb(200, 220, 255) Note over User,Browser: User initiates login User->>Browser: 4. Click "Sign in with Okta" end rect rgb(255, 220, 200) Note over PP,IdP: SAML Authentication Request (AuthnRequest) Browser->>PP: 5. POST /signin-saml2 PP->>PP: 6. Generate SAML AuthnRequest XML
(Issuer, ACS URL, ID, Timestamp) PP->>Browser: 7. HTTP 302 Redirect with encoded SAML Request Browser->>IdP: 8. GET /sso?SAMLRequest=... end rect rgb(200, 255, 220) Note over User,IdP: User Authentication Phase IdP->>IdP: 9. Decode & validate SAML Request IdP->>Browser: 10. Show login page User->>Browser: 11. Enter username/password Browser->>IdP: 12. POST credentials IdP->>IdP: 13. Validate credentials end rect rgb(255, 255, 200) Note over IdP,PP: SAML Response (Assertion) Generation IdP->>IdP: 14. Create SAML Assertion XML
(Issuer, NameID, Attributes, Conditions) IdP->>IdP: 15. Sign XML with X.509 certificate IdP->>Browser: 16. Auto-submit HTML form with SAMLResponse Browser->>PP: 17. POST /signin-saml2 with SAMLResponse end rect rgb(220, 200, 255) Note over PP: Assertion Validation & Session Creation PP->>PP: 18. Decode SAML Response PP->>PP: 19. Validate XML signature (using IdP public key) PP->>PP: 20. Check Issuer, Audience, NotBefore, NotOnOrAfter PP->>PP: 21. Extract NameID & Attributes PP->>PP: 22. Create/update user in Dataverse PP->>PP: 23. Create session cookie end PP->>Browser: 24. Set-Cookie + Redirect to original page Browser->>PP: 25. Request original page with cookie PP->>Browser: 26. Return protected content Browser->>User: 27. Display page
💡 Diagramm-Legende: Beachten Sie, wie SAML XML (nicht JSON) verwendet und die gesamte Assertion signiert, anstatt einen Backend-Token-Austausch wie OAuth zu verwenden.
Erforderliche Parameter
Diese Parameter müssen konfiguriert werden, damit die SAML-Authentifizierung funktioniert:
| Parameter | Beschreibung | Beispielwert |
|---|---|---|
| Provider NameERFORDERLICH | Der Text, der auf dem Anmelde-Button angezeigt wird | "Mit Okta anmelden" "Mit Firmen-SSO anmelden" |
| Metadata AddressERFORDERLICH | Die SAML 2.0 Federation Metadata-Dokument-URL. Dieses XML-Dokument enthält alle SAML-Endpunkte, Zertifikate und unterstützten Features. Power Pages analysiert dies automatisch, um die SAML-Kommunikation zu konfigurieren. | https://login.microsoftonline.com/{tenant-id}/federationmetadata/2007-06/federationmetadata.xml (Entra ID)https://yourorg.okta.com/app/{app-id}/sso/saml/metadata (Okta) |
| Authentication TypeERFORDERLICH | Der entityID-Wert aus dem SAML-Metadata-Dokument. Dieser identifiziert den Identity Provider eindeutig. Sie finden diesen, indem Sie die Metadata Address-URL in einem Browser öffnen und den <entityID>-Tag-Wert aus dem root <EntityDescriptor>-Element kopieren. |
https://sts.windows.net/{tenant-id}/ (Entra ID)http://www.okta.com/{externalKey} (Okta) |
| Service Provider RealmERFORDERLICH | Die App-ID-URI aus Ihrer IdP-App-Registrierung. Diese identifiziert Ihre Power Pages-Site beim IdP (auch Audience in SAML-Begriffen genannt). Muss genau mit dem übereinstimmen, was Sie im IdP als SP Entity ID oder Audience konfiguriert haben. | https://yoursite.powerappsportals.com/api://{app-id} (bei Verwendung der automatisch generierten Entra ID-URI) |
| Assertion Consumer Service URLERFORDERLICH | Die Power Pages Callback-URL, an die der IdP SAML-Assertions nach der Authentifizierung sendet (auch ACS-URL genannt). Wird automatisch von Power Pages generiert. Bei Custom Domains diesen Wert aktualisieren. Muss mit der im IdP konfigurierten ACS-URL oder Reply-URL übereinstimmen. | https://yoursite.powerappsportals.com/signin-saml2https://customdomain.com/signin-saml2 |
Optionale / Erweiterte Parameter
| Parameter | Beschreibung | Standard / Anwendungsfall |
|---|---|---|
| Validate AudienceOPTIONAL | Aktiviert die Audience-Validierung während der SAML-Assertion-Validierung. Wenn aktiviert, prüft Power Pages, dass das Audience-Element in der SAML-Assertion einem Ihrer Valid Audiences-Werte entspricht. Dies verhindert Assertion Replay-Angriffe. |
Off (Standard) Produktions-Empfehlung: Für Sicherheit aktivieren |
| Valid AudiencesOPTIONAL | Kommagetrennte Liste erlaubter Audience-Werte. Nur SAML-Assertions mit diesen Audience-Werten werden akzeptiert. Sollte mit Ihrem Service Provider Realm übereinstimmen. | https://yoursite.powerappsportals.com/https://site1.powerappsportals.com/,https://site2.powerappsportals.com/Requires: Validate Audience = On |
| Contact Mapping with EmailOPTIONAL | Verknüpft IdP-Identität automatisch mit Dataverse-Kontakt basierend auf E-Mail-Adress-Übereinstimmung. On: Mit bestehendem Kontakt verknüpfen, wenn E-Mail übereinstimmt Off: Immer neuen Kontakt für jede neue SAML-Identität erstellen |
On (Standard - empfohlen) Wichtig: Stellen Sie sicher, dass der IdP den E-Mail-Claim in der SAML-Assertion sendet (NameID oder E-Mail-Attribut) |
🔍 So finden Sie die entityID (Authentication Type)
- Kopieren Sie die Metadata Address-URL von Ihrem IdP
- Fügen Sie sie in einen Webbrowser ein
- Sie sehen ein XML-Dokument
- Suchen Sie nach dem
<EntityDescriptor entityID="...">-Tag oben - Kopieren Sie den
entityID-Wert - das ist Ihr Authentication Type
Beispiel: In <EntityDescriptor entityID="https://sts.windows.net/abc123/"> ist die entityID https://sts.windows.net/abc123/
✅ SAML 2.0 Empfehlungen und ❌ Fehler
EMPFOHLEN - SAML Best Practices
- ✅ Always verify metadata URL is accessible - Open in browser, should return XML without authentication
- ✅ Copy entityID exactly from metadata - Including protocol (http vs https), trailing slash, casing
- ✅ Match Service Provider Realm to IdP configuration - Must be exactly what you configured as SP Entity ID in IdP
- ✅ Configure Name ID format in IdP - Persistent or Email format works best for Power Pages
- ✅ Send email claim in SAML assertion - Either as NameID or as separate email attribute claim
- ✅ Test assertion in SAML decoder tool - Use browser extension to decode SAML response, verify claims
- ✅ Turn on Validate Audience in production - Prevents assertion replay attacks
- ✅ Use SHA-256 signing algorithm - SHA-1 is deprecated and may be rejected
- ✅ Configure assertion expiry appropriately - 5-10 minutes is typical, not too short (clock skew) or too long (security)
- ✅ Document certificate renewal process - SAML certificates expire, plan renewal in advance
VERMEIDEN - SAML-Fallstricke
- ❌ Don't confuse Service Provider Realm with ACS URL - They serve different purposes (WHO you are vs WHERE to send response)
- ❌ Don't use same value for Realm and ACS URL - Common mistake, causes validation errors
- ❌ Don't type entityID manually - Copy exact value from metadata XML including protocol and trailing characters
- ❌ Don't forget to configure claim rules in IdP - Power Pages needs at minimum NameID claim (email)
- ❌ Don't use SHA-1 signing algorithm - Deprecated, may cause security warnings or rejections
- ❌ Don't ignore certificate expiry - SAML certs expire (typically 1-3 years), plan renewal process
- ❌ Don't test only SP-initiated flow - Some IdPs require IdP-initiated flow configuration too
- ❌ Don't assume SAML = OAuth - Different protocols, different configuration, different error messages
- ❌ Don't skip metadata validation - Verify metadata contains SingleSignOnService and signing certificate
- ❌ Don't forget clock skew tolerance - Ensure IdP and Power Pages servers have synchronized time (NTP)
🚨 Top 5 SAML-Konfigurationsfehler
1. Service Provider Realm vs. ACS URL Confusion
Problem: Using the same value for both fields, or swapping them
Symptom: SAML assertion validation errors, "Audience mismatch" or "Invalid destination"
Fix: Service Provider Realm = WHO you are (your SP entity ID, usually your site URL). ACS URL = WHERE to send response (callback endpoint with /signin-saml2). These must be different!
2. Wrong entityID (Authentication Type)
Problem: entityID doesn't match what's in metadata document (typo, wrong protocol, missing trailing slash)
Symptom: "Unknown issuer" or "Issuer mismatch" errors
Fix: Open metadata URL in browser, find <EntityDescriptor entityID="...">, copy EXACT value. Check http vs https, trailing slash.
3. Missing Email Claim
Problem: IdP doesn't send email claim in SAML assertion, or sends it in unexpected format
Symptom: Users can authenticate but contact record has no email, or authentication succeeds but user can't be identified
Fix: Configure IdP to send email as NameID (format: EmailAddress or Persistent), or as separate http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress claim. Use SAML decoder to verify.
4. Metadata URL Not Accessible
Problem: Metadata URL requires authentication, behind firewall, or returns HTML instead of XML
Symptom: "Unable to retrieve metadata" or "Invalid metadata document" errors
Fix: Metadata must be publicly accessible URL returning valid XML. Test in browser without authentication. For on-prem IdPs, ensure URL is accessible from internet.
5. Clock Skew Issues
Problem: Time difference between IdP server and Power Pages service causes assertion validation failures
Symptom: Intermittent "Assertion expired" or "Assertion not yet valid" errors, especially for users in different timezones
Fix: Ensure IdP server uses NTP for time synchronization. Configure assertion validity period to 5-10 minutes (allows for some clock skew). Test from different locations/timezones.
🎯 SAML 2.0 Best Practices
Für Identity Provider-Administratoren (Okta, Entra ID, Ping)
SAML-Anwendungs-Setup
- Beschreibende App-Namen verwenden - "Power Pages Customer Portal (Production)" nicht "SAML App 1"
- Single Sign-On URL (ACS URL) korrekt konfigurieren - Muss mit
/signin-saml2enden - SP Entity ID auf Website-URL setzen -
https://yoursite.powerappsportals.com/oder benutzerdefinierte Domain verwenden - Name ID Format konfigurieren - "Persistent" oder "Email" Format für beste Kompatibilität verwenden
- Metadata öffentlich zugänglich machen - Power Pages muss Metadata ohne Authentifizierung abrufen können
Claim-Konfiguration
- E-Mail-Claim immer senden - Als NameID oder als
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddresssenden - Vorname und Nachname senden, falls verfügbar -
givenNameundsurnameAttributnamen verwenden - Erwägen Sie das Senden von Gruppenmitgliedschaften - Kann für Power Pages Rollenzuweisung verwendet werden
- Claims mit SAML-Decoder testen - Browser-Erweiterung oder Online-Tool verwenden, um SAML-Response zu dekodieren, überprüfen, dass alle erwarteten Claims ankommen
Zertifikat-Verwaltung
- SHA-256 Signaturalgorithmus verwenden - SHA-1 ist veraltet
- Kalender-Erinnerungen für Zertifikat-Ablauf setzen - Typischerweise 1-3 Jahre, 60 Tage vor Ablauf prüfen
- Zertifikate ohne Ausfallzeit rotieren - Neues Zertifikat neben altem konfigurieren, Metadata aktualisieren, dann altes entfernen
- Neues Zertifikat in Metadata vor Aktivierung veröffentlichen - Ermöglicht Power Pages, neues Zertifikat vorab zu cachen
Sicherheitseinstellungen
- Assertions signieren, nicht nur Responses - Sicherer, verhindert Assertion-Substitutions-Angriffe
- Assertion-Gültigkeit auf 5-10 Minuten setzen - Balance zwischen Zeitversatz-Toleranz und Sicherheit
- Nicht mit SHA-1 signieren - SHA-256 oder höher verwenden
- Audience-Einschränkung aktivieren - Begrenzt Assertion auf spezifischen SP (Ihre Power Pages-Website)
Für Power Pages Administratoren
Konfiguration & Testen
- Kopieren Sie Assertion Consumer Service URL aus Power Pages - Nicht manuell eingeben, Kopieren-Schaltfläche verwenden
- Überprüfen Sie, dass Service Provider Realm mit IdP-Konfiguration übereinstimmt - Muss exakt übereinstimmen (Groß-/Kleinschreibung, abschließender Schrägstrich relevant)
- Testen Sie Metadata URL vor der Konfiguration - Im Browser öffnen, sollte XML-Dokument zurückgeben
- Kopieren Sie entityID aus Metadata XML - Nicht raten, exakten Wert aus
<EntityDescriptor>kopieren - Aktivieren Sie Diagnoseprotokollierung vor dem Testen - SAML-Fehler sind ausführlich, Protokolle sind essenziell für Debugging
- Verwenden Sie SAML-Decoder-Browser-Erweiterung - SAML-Response dekodieren, um genau zu sehen, was IdP sendet
Fehlerbehebungs-Werkzeuge
- Browser-Erweiterung: SAML-tracer oder SAML DevTools - Erfasst und dekodiert SAML-Anfragen/-Antworten
- Online SAML-Decoder - samltool.com zum Dekodieren von Assertions
- Power Pages Diagnoseprotokolle - Enthält vollständige SAML-Assertion-Validierungsfehler
- IdP-Anmeldeprotokolle - Prüfen, ob Authentifizierung bei IdP erfolgreich ist, bevor SAML-Response gesendet wird
Produktionsbereitschaft
- Aktivieren Sie Validate Audience - Setzen Sie Valid Audiences auf Ihren Service Provider Realm Wert
- Dokumentieren Sie Zertifikat-Ablaufdatum - Zu Projektdokumentation hinzufügen, Kalender-Erinnerungen setzen
- Testen Sie aus mehreren Netzwerken - Unternehmens-VPN, Heiminternet, Mobil - Erreichbarkeit sicherstellen
- Überprüfen Sie, dass Contact Mapping with Email aktiviert ist - Verhindert doppelte Kontakterstellung
Für Berater & Entwickler
SAML Fehlerbehebungs-Checkliste
- Schritt 1: Metadata-Erreichbarkeit überprüfen - Metadata URL im Browser öffnen, sollte XML zurückgeben
- Schritt 2: entityID-Übereinstimmung prüfen - Authentication Type in Power Pages mit
<EntityDescriptor entityID>in Metadata vergleichen - Schritt 3: Service Provider Realm mit IdP abgleichen - Muss mit SP Entity ID übereinstimmen, die im IdP konfiguriert ist
- Schritt 4: ACS URL auf Korrektheit prüfen - Muss mit
/signin-saml2enden und mit IdP-Konfiguration übereinstimmen - Schritt 5: SAML-Decoder verwenden - SAML-Response erfassen, dekodieren, Claims überprüfen (E-Mail, Name, etc.)
- Schritt 6: Power Pages Diagnoseprotokolle prüfen - Nach spezifischen SAML-Validierungsfehlern suchen
- Schritt 7: Zertifikat-Gültigkeit überprüfen - Ablaufdatum prüfen, Signaturalgorithmus (sollte SHA-256+ sein)
Häufige SAML-Fehlermeldungen
- "Unknown issuer" → entityID (Authentication Type) stimmt nicht mit dem in Assertion überein
- "Audience mismatch" → Service Provider Realm stimmt nicht mit Audience in Assertion überein, oder Validate Audience ist Ein, aber Valid Audiences ist falsch
- "Invalid destination" → ACS URL in Assertion stimmt nicht mit konfigurierter Assertion Consumer Service URL überein
- "Assertion expired" → Zeitversatz zwischen IdP und Power Pages, oder Assertion-Gültigkeitsdauer zu kurz
- "Signature validation failed" → Zertifikat-Mismatch, abgelaufenes Zertifikat oder falscher Signaturalgorithmus
- "Missing NameID" → IdP sendet keinen NameID Claim, Claim-Regeln im IdP prüfen
Projekt-Dokumentation
- Screenshot der IdP SAML-Konfiguration - SP Entity ID, ACS URL, NameID-Format, Claim-Regeln
- Metadata URL und entityID speichern - Essenziell für Fehlerbehebung
- Zertifikat-Ablaufprozess dokumentieren - Wer erneuert, wie oft, Benachrichtigungsprozess
- SAML-Fehler-Runbook erstellen - Während des Testens aufgetretene Fehler mit Lösungen dokumentieren
- Benutzerdokumentation bereitstellen - SAML-Login-Flow erklären, was passiert, wenn Zertifikat abläuft, Support-Kontakt
🔒 Session-Sicherheit Deep Dive
The Big Question: "If the session cookie is the key to entry, can I just copy it to another machine and be authenticated?"
The Short Answer
Technically: Yes, you could copy the cookie and gain access.
In practice: Power Pages implements security measures to make this harder (but not impossible).
⚠️ Why This Matters
Session hijacking (cookie theft) is a real security concern. If an attacker gets your session cookie, they can impersonate you until the cookie expires.
The Risk: An attacker with your cookie doesn't need your password. They're already "in."
🛡️ Security Measures in Power Pages Session Cookies
Power Pages session cookies have these built-in protections:
| Security Flag | What It Does | Attack It Prevents |
|---|---|---|
| HttpOnly ✅ | JavaScript cannot read the cookie | XSS attacks trying to steal cookies |
| Secure ✅ | Cookie only sent over HTTPS | Network interception on unencrypted connections |
| SameSite ✅ | Cookie won't be sent from other domains | CSRF (Cross-Site Request Forgery) attacks |
| Short Expiry ✅ | Cookie expires after 8 hours (typical) | Limits window for abuse if stolen |
❌ What Power Pages DOESN'T Check (by default)
- ❌ IP address - Cookie works from any IP address
- ❌ User agent - Cookie works in any browser
- ❌ Device fingerprint - No device binding
- ❌ Geolocation - No location validation
This means: If an attacker gets your cookie, they can use it from a different machine/location until it expires.
🎭 Real-World Attack Scenarios
Scenario 1: Malware on User's Machine
Attack:
- 1. Attacker installs malware on user's computer
- 2. Malware reads browser cookies from disk
- 3. Malware sends cookies to attacker's server
- 4. Attacker uses cookie on their machine → Full access until expiry
Defense:
- ✅ Antivirus software (user responsibility)
- ✅ Keep OS and browser updated
- ✅ Short session timeout (admin control)
- ✅ User education (don't use shared devices)
Scenario 2: Network Sniffing (Mitigated by HTTPS)
Attack:
- 1. User on public WiFi without HTTPS
- 2. Attacker captures network traffic
- 3. Attacker extracts session cookie
- 4. Attacker replays cookie → Session hijacked
Defense:
- ✅ Power Pages forces HTTPS (built-in protection)
- ✅ Secure flag on cookies (prevents transmission over HTTP)
- ⚠️ Still vulnerable if user ignores certificate warnings
Scenario 3: XSS Attack (Mitigated by HttpOnly)
Attack:
- 1. Attacker finds vulnerability in custom portal script
- 2. Attacker injects JavaScript:
document.cookie - 3. Script tries to read session cookie
- 4. HttpOnly flag blocks access ✅
Defense:
- ✅ HttpOnly flag (built-in to Power Pages)
- ✅ Content Security Policy (configure in portal)
- ✅ Input validation on all forms
- ✅ Regular security audits of custom code
🔧 So minimieren Sie das Risiko
Für Power Pages Administratoren:
1. Kurze Session-Timeouts (z.B. 2-4 Stunden statt 8)
- • Auf Power Pages-Ebene konfiguriert
- • Balance zwischen Sicherheit und Benutzerfreundlichkeit
- • Begrenzt Schadensfenster, falls Cookie gestohlen wird
2. Conditional Access Policies (Entra External ID, erfordert Premium-Lizenz)
- ✅ Einschränkung nach IP-Bereich (z.B. nur Unternehmensnetzwerk)
- ✅ Verdächtige Standorte blockieren (z.B. Länder, in denen Sie nicht tätig sind)
- ✅ Konformes Gerät erforderlich
- ⚠️ Konfigurationskomplexität variiert je nach IdP
3. Session-Aktivität überwachen
- • Diagnoseprotokollierung in Power Pages aktivieren
- • Entra External ID Anmeldeprotokolle regelmäßig überprüfen
- • Nach ungewöhnlichen Mustern suchen (siehe Überwachungsabschnitt unten)
4. Web Application Firewall (WAF) verwenden
- • Azure Front Door oder ähnlich
- • Kann Session-Hijacking-Muster erkennen (z.B. gleiches Cookie von mehreren IPs)
- • Rate Limiting zur Verhinderung von Brute-Force
5. Benutzerdefinierte Session-Validierung implementieren
- • Power Pages Web API oder benutzerdefinierten Code verwenden
- • Auf verdächtiges Verhalten prüfen (z.B. schneller Seitenzugriff)
- • Re-Authentifizierung auslösen, falls erforderlich
Für Endbenutzer:
⚠️ Wichtig: Als Portal-Benutzer haben Sie KEINE Kontrolle über Session-Timeouts oder Sicherheitsrichtlinien. Diese werden vom Identity Provider Administrator und Power Pages Administrator gesteuert.
Was Sie tun KÖNNEN, um sich zu schützen:
- 🚫 Greifen Sie niemals auf sensible Portale auf gemeinsam genutzten/öffentlichen Computern zu
- 🚫 Bleiben Sie nicht unnötig angemeldet (melden Sie sich ab, wenn Sie fertig sind)
- ✅ Halten Sie Browser und OS aktuell (Sicherheitspatches)
- ✅ Verwenden Sie Antivirensoftware
- ✅ Seien Sie vorsichtig bei öffentlichem WLAN (verwenden Sie VPN, wenn möglich)
- ✅ Löschen Sie Browser-Cookies nach Verwendung gemeinsam genutzter Geräte
- ✅ Melden Sie verdächtige Anmelde-Benachrichtigungen sofort
Wenn Sie strengere Sicherheitsmaßnahmen benötigen, kontaktieren Sie Ihren Portal-Administrator.
🔍 Cookie-Diebstahl erkennen
Zu überwachende Warnsignale:
| Indikator | Was es bedeutet | Maßnahme |
|---|---|---|
| Gleicher Benutzer, verschiedene IPs gleichzeitig | Möglicher Cookie-Diebstahl | Abmeldung erzwingen, Re-Authentifizierung erforderlich |
| Anmeldung von unmöglichen Standorten | Kann nicht gleichzeitig in USA und China sein (5 Min. Abstand) | Session blockieren, Benutzer benachrichtigen |
| Schnelle Anfragen von einzelner Session | Automatisierter Angriff oder Daten-Scraping | Rate Limit, CAPTCHA oder blockieren |
| User Agent ändert sich plötzlich | Cookie in anderem Browser verwendet | Optional: Re-Authentifizierung bei hoher Sicherheit |
⚠️ Realitäts-Check: Was Sie tatsächlich überwachen können
Out-of-the-Box (Keine zusätzlichen Tools):
Als Power Pages Administrator:
- ✅ Diagnoseprotokolle (nur Fehler und Ausfälle)
- ❌ KEINE IP-Adressen, User Agents oder Session-Details
- ❌ KEINE Echtzeit-Überwachungsfunktionen
Als Entra External ID Administrator:
- ✅ Anmeldeprotokolle (Azure Portal → Entra External ID → Überwachung → Anmeldeprotokolle)
- ✅ Zeigt: IP, Standort, Gerät, Browser, Erfolg/Fehler
- ⚠️ Erfasst nur LOGIN-Ereignisse, NICHT laufende Session-Aktivität
- ❌ Kann nicht erkennen, ob dasselbe Cookie gleichzeitig von mehreren IPs verwendet wird
Um die oben genannten Warnsignale tatsächlich zu erkennen, benötigen Sie:
| Tool | Was es tut | Kosten |
|---|---|---|
| Azure Application Insights | Power Pages Anfragen, IPs, Sessions verfolgen | Pay-per-use (~€2-5/GB aufgenommen) |
| Azure Monitor + Log Analytics | Anmeldeprotokolle + Power Pages Protokolle korrelieren | Pay-per-use (~€2,50/GB) |
| Microsoft Entra ID Protection | Automatische Risikoerkennung (unmögliches Reisen, etc.) | Premium P2 (~€8-10/Benutzer/Monat) |
| SIEM (z.B. Microsoft Sentinel) | Erweiterte Bedrohungserkennung, benutzerdefinierte Regeln | Enterprise-Preise (~€200+/Monat) |
Fazit: Die Warnsignale-Tabelle zeigt, was Sie überwachen sollten, aber deren Erkennung erfordert zusätzliche Tools und Budget. Für die meisten Power Pages-Implementierungen ist dieses Überwachungsniveau nur für Hochsicherheitsszenarien gerechtfertigt (Finanzdaten, Gesundheitswesen, Admin-Portale).
📊 Was Sie ohne zusätzliche Tools tun können
Praktischer Ansatz für die meisten Projekte:
- 1. Entra External ID Anmeldeprotokolle aktivieren (kostenlos, immer aktiv)
- • Wöchentlich auf ungewöhnliche Anmeldemuster überprüfen
- • Nach Anmeldungen aus unerwarteten Ländern suchen
- • Fehlgeschlagene Anmeldeversuche prüfen (Brute-Force?)
- 2. Power Pages Diagnoseprotokollierung aktivieren (kostenlos)
- • Erfasst Authentifizierungsfehler
- • Hilft beim Debuggen von Anmeldeproblemen
- • Erfasst kein Session-Hijacking, zeigt aber Systemzustand
- 3. Conditional Access implementieren (Entra External ID, erfordert Premium-Lizenz)
- • Anmeldungen nach IP-Bereich einschränken (z.B. nur Unternehmensnetzwerk)
- • Hochrisiko-Länder blockieren
- • Gerätekonformität erforderlich
- • Prävention ist besser (und günstiger) als Erkennung!
- 4. Kurze Session-Timeouts (Power Pages Einstellung, kostenlos)
- • Von 8 Stunden auf 2-4 Stunden reduzieren
- • Begrenzt Schadensfenster, falls Cookie gestohlen wird
- • Keine zusätzlichen Tools erforderlich
- 5. Benutzerschulung (kostenlos!)
- • Benutzer auffordern, sich auf gemeinsam genutzten Geräten abzumelden
- • Vor Phishing-Versuchen warnen
- • Klaren Kontakt für "verdächtige Aktivität melden" bereitstellen
📊 Session-Sicherheits-Vergleich
| Sicherheitsmaßnahme | Power Pages Standard | Zusätzlicher verfügbarer Schutz |
|---|---|---|
| HTTPS-Erzwingung | ✅ Immer aktiv | - |
| HttpOnly Cookies | ✅ Aktiviert | - |
| Secure Flag | ✅ Aktiviert | - |
| SameSite Attribut | ✅ Aktiviert | - |
| IP-Bindung | ❌ Nicht Standard | ⚠️ Über Conditional Access (Entra External ID) |
| Geräte-Bindung | ❌ Nicht verfügbar | ⚠️ Über Conditional Access (Entra External ID) |
| Geolokalisierungs-Prüfungen | ❌ Nicht Standard | ✅ Über Conditional Access (Entra External ID) |
| Zusätzliche Authentifizierungsfaktoren | ❌ Nicht eingebaut | ⚠️ Auf IdP-Ebene konfigurieren (komplexes Setup) |
💡 The Bottom Line
Session cookies ARE vulnerable to theft - this is true for ALL web applications, not just Power Pages.
The defense is layered security:
- 1. Base protections (HTTPS, HttpOnly, Secure flag) → Built-in ✅
- 2. Short session timeouts → Limits damage window ✅
- 3. Conditional Access → Blocks suspicious activity ⚠️ (Premium license)
- 4. Monitoring & alerts → Detect and respond quickly ⚠️ (Extra tools needed)
- 5. User education → Prevent careless mistakes ✅ (Free!)
No single measure is perfect - but together, they make stealing sessions significantly harder and less valuable.
🎯 Should You Worry?
Low Risk Scenarios:
- • Public marketing portal (no sensitive data)
- • Internal portal on corporate network only
- • Short sessions (2-4 hours) with Conditional Access enabled
High Risk Scenarios:
- • Portal with financial transactions
- • Access to personal health information
- • Administrative functions (user management, settings)
- • Publicly accessible with sensitive data
Recommendation: For high-risk scenarios, implement all available protections (short sessions + Conditional Access + monitoring + WAF). Consider additional security measures like step-up authentication for critical operations.
Fazit
Authentifizierung in Power Pages sind im Grunde drei Freunde, die sich Nachrichten übergeben: Sie, Ihr Portal und Microsoft (oder Google, etc.).
🎯 Merken Sie sich diese 5 Dinge
- Verwenden Sie OAuth/OpenID Connect - Das ist der moderne Weg. SAML ist für Legacy-Systeme.
- Es geht um Vertrauen - Ihr Portal vertraut Microsofts digitaler Signatur, wie einem Passstempel.
- Sicherheit geschieht in Schritten - Mehrere Weiterleitungen = sicherer (kein Bug!)
- Token haben Ablaufdaten - Normalerweise 1 Stunde. Das ist normal.
- Prüfen Sie, ob Ihre URLs exakt übereinstimmen - Die meisten Auth-Fehler = falsche Redirect-URL
Power Pages Leute vereinigt euch! Lasst euch nicht von diesen Sidekick-Produkten besiegen 😜
Jetzt verstehen Sie, wie die Anmeldung funktioniert. Wenn etwas kaputt geht, wissen Sie, wo Sie suchen müssen.
🌐 Social Identity Providers (Schnelle Einrichtung für B2C)
Was sind Social Identity Providers?
Power Pages enthält 5 vorkonfigurierte OAuth 2.0-Provider für Consumer-Authentifizierungsszenarien. Dies sind vereinfachte, assistentenbasierte Alternativen zur generischen OAuth/OIDC-Einrichtung aus dem vorherigen Abschnitt.
Wichtige Einschränkung: Power Pages unterstützt keine anderen OAuth-Provider außer diesen fünf. Verwenden Sie für Custom Provider (wie Auth0, Okta oder Ihren eigenen OAuth-Server) stattdessen die generische OpenID Connect-Konfiguration.
Unterstützte Social Provider
Konfigurationsparameter
Social Identity Provider benötigen nur 2-3 Konfigurationswerte in Power Pages:
https://yoursite.powerappsportals.com/signin-{provider}Examples:
•
/signin-google•
/signin-facebook•
/signin-microsoftOptionale zusätzliche Einstellungen
Alle Social Provider teilen diese optionalen erweiterten Einstellungen (erweitern Sie "Zusätzliche Einstellungen" im Power Pages-Assistenten):
email,profile)Social OAuth vs. Generisches OAuth/OIDC
Wann sollten Social Identity Providers verwendet werden?
✅ Verwenden Sie Social OAuth wenn:
❌ Verwenden Sie stattdessen Generisches OAuth/OIDC wenn:
🎯 Social IdP Best Practices
Sicherheits- & Datenschutzüberlegungen
emailif you need email, don't ask forprofileunnecessarily)Häufige Fallstricke mit Social IdPs
Multi-Provider-Setup-Strategie
Viele Portale bieten mehrere Social Login-Optionen an. Hier ist der empfohlene Ansatz: