Static Web App Authentication broken — cookies cannot be decrypted; /.auth/me returns clientPrincipal:null; Root returns 401

Hallo folgender Text ist von Copilot erstellt. :-)

Meine Static Web App kann sich nicht mehr authentifizieren. Der interaktive Login über /.auth/login/aad funktioniert (Redirects zu identity.2.azurestaticapps.net und zu login.microsoftonline.com), Cookies werden gesetzt, aber die SWA kann die Session nicht erkennen oder die Cookies nicht entschlüsseln. /.auth/me liefert immer clientPrincipal: null. Root‑Requests liefern 401 Unauthorized ohne Redirect. Dieses Verhalten tritt auch bei einer frisch erstellten SWA auf und deutet auf einen defekten internen Auth‑State (Encryption key / service principal / identity proxy) hin.

Detaillierte Symptome / Beobachtungen:

GET https://polite-beach-06798a203.2.azurestaticapps.net/.auth/login/aad → vollständige Redirect‑Kette zu identity.2.azurestaticapps.net → login.microsoftonline.com (302 → 302 → 302 → 200). Cookies StaticWebAppsAuthContextCookie und weitere werden gesetzt.

Nach Login: GET https://polite-beach-06798a203.2.azurestaticapps.net/.auth/me → 200 OK mit JSON { "clientPrincipal": null }.

GET https://polite-beach-06798a203.2.azurestaticapps.net/ (Root) → 401 Unauthorized, kein Location: Header (also kein Redirect zum Login).

Login‑Cookies werden vom Client gesendet (siehe Cookie: StaticWebAppsAuthContextCookie=...), die SWA akzeptiert/entschlüsselt sie jedoch nicht.

curl -i -H "Accept: text/html" https://polite-beach-.../admin/ liefert 200 OK und die index.html (Routen/Rewrite greifen), während Root 401 liefert — inkonsistentes Auth‑Verhalten.

Verhalten tritt auch bei einer neu erstellten SWA mit Simple‑Auth auf.

Bereits durchgeführte Tests (mit Ergebnissen):

curl -i -L /.auth/login/aad → erfolgreiche Redirects und Set‑Cookie.

curl -i -b cookiejar /.auth/me → 200 mit clientPrincipal: null.

curl -i -b cookiejar / → 401 Unauthorized (Cookie wurde gesendet, aber nicht akzeptiert).

Test mit Accept: text/html ergab weiterhin 401 für Root.

Neue SWA erstellt; Verhalten identisch.

Wahrscheinliche Ursache (Analyse): Die SWA erhält die Auth‑Cookies, kann diese aber nicht entschlüsseln/validieren. Das deutet auf einen defekten internen Auth‑Zustand (z. B. abgelaufener/fehlerhafter interner Encryption Key, fehlgeschlagene Key‑Rotation, beschädigter Service Principal oder fehlerhafte Verknüpfung des Identity‑Proxy). Da das Problem auch bei einer neuen SWA auftritt, liegt die Ursache sehr wahrscheinlich auf Azure‑Seite (SWA Authentication Service / identity proxy / key management).

Erwartetes Verhalten:

Nach erfolgreichem Login sollte /.auth/me ein gültiges clientPrincipal mit Claims zurückliefern.

Unauthenticated Root‑Requests sollten einen Redirect zum Login auslösen (Location → identity / login.microsoftonline.com) oder die SWA sollte die Session akzeptieren, wenn gültige Cookies vorhanden sind.

Gewünschte Aktion / Dringlichkeit: Bitte prüft und setzt die interne Auth‑Konfiguration für die betroffene SWA zurück oder repariert die interne Schlüssel/Service‑Principal‑Verknüpfung. Konkrete Maßnahmen, die helfen würden:

Überprüfen und ggf. Zurücksetzen der internen Encryption Keys / Key‑Rotation für den Static Web Apps Authentication Service.

Überprüfen des Service Principal / Identity Proxy, der für identity.2.azurestaticapps.net zuständig ist, und Neuverknüpfung mit der betroffenen SWA.

Falls erforderlich, Zurücksetzen der Auth‑Konfiguration für die betroffene SWA‑Ressource oder Migration der internen Auth‑State auf einen konsistenten Zustand.

Kurze Rückmeldung mit den durchgeführten Schritten und, falls nötig, einem Zeitfenster für die Reparatur.

Logs / Anhänge (relevant):

• Beispiel‑Header‑Auszüge und curl‑Outputs (Datum 21.05.2026) — kann ich auf Anfrage als Text anhängen.

Sign‑in logs zeigen erfolgreiche Redirects bis 15.05.2026; danach fehlschlagende Sessions (Details können wir bei Bedarf bereitstellen).Meine Static Web App kann sich nicht mehr authentifizieren. Der interaktive Login über /.auth/login/aad funktioniert (Redirects zu identity.2.azurestaticapps.net und zu login.microsoftonline.com), Cookies werden gesetzt, aber die SWA kann die Session nicht erkennen oder die Cookies nicht entschlüsseln. /.auth/me liefert immer clientPrincipal: null. Root‑Requests liefern 401 Unauthorized ohne Redirect. Dieses Verhalten tritt auch bei einer frisch erstellten SWA auf und deutet auf einen defekten internen Auth‑State (Encryption key / service principal / identity proxy) hin.

Detaillierte Symptome / Beobachtungen:

GET https://polite-beach-06798a203.2.azurestaticapps.net/.auth/login/aad → vollständige Redirect‑Kette zu identity.2.azurestaticapps.net → login.microsoftonline.com (302 → 302 → 302 → 200). Cookies StaticWebAppsAuthContextCookie und weitere werden gesetzt.

  Nach Login: `GET https://polite-beach-06798a203.2.azurestaticapps.net/.auth/me` → **200 OK** mit JSON `{ "clientPrincipal": null }`.
  
     `GET https://polite-beach-06798a203.2.azurestaticapps.net/` (Root) → **401 Unauthorized**, **kein** `Location:` Header (also kein Redirect zum Login).
     
        Login‑Cookies werden vom Client gesendet (siehe `Cookie: StaticWebAppsAuthContextCookie=...`), die SWA akzeptiert/entschlüsselt sie jedoch nicht.
        
           `curl -i -H "Accept: text/html" https://polite-beach-.../admin/` liefert **200 OK** und die index.html (Routen/Rewrite greifen), während Root 401 liefert — inkonsistentes Auth‑Verhalten.
           
              Verhalten tritt auch bei einer neu erstellten SWA mit Simple‑Auth auf.
              
              **Bereits durchgeführte Tests (mit Ergebnissen):**
              
                 `curl -i -L /.auth/login/aad` → erfolgreiche Redirects und Set‑Cookie.
                 
                    `curl -i -b cookiejar /.auth/me` → `200` mit `clientPrincipal: null`.
                    
                       `curl -i -b cookiejar /` → `401 Unauthorized` (Cookie wurde gesendet, aber nicht akzeptiert).
                       
                          Test mit `Accept: text/html` ergab weiterhin 401 für Root.
                          
                             Neue SWA erstellt; Verhalten identisch.
                             
                             **Wahrscheinliche Ursache (Analyse):**   Die SWA erhält die Auth‑Cookies, kann diese aber nicht entschlüsseln/validieren. Das deutet auf einen defekten internen Auth‑Zustand (z. B. abgelaufener/fehlerhafter interner Encryption Key, fehlgeschlagene Key‑Rotation, beschädigter Service Principal oder fehlerhafte Verknüpfung des Identity‑Proxy). Da das Problem auch bei einer neuen SWA auftritt, liegt die Ursache sehr wahrscheinlich auf Azure‑Seite (SWA Authentication Service / identity proxy / key management).
                             
                             **Erwartetes Verhalten:**
                             
                                Nach erfolgreichem Login sollte `/.auth/me` ein gültiges `clientPrincipal` mit Claims zurückliefern.
                                
                                   Unauthenticated Root‑Requests sollten einen Redirect zum Login auslösen (Location → identity / login.microsoftonline.com) oder die SWA sollte die Session akzeptieren, wenn gültige Cookies vorhanden sind.
                                   
                                   **Gewünschte Aktion / Dringlichkeit:**   Bitte prüft und setzt die interne Auth‑Konfiguration für die betroffene SWA zurück oder repariert die interne Schlüssel/Service‑Principal‑Verknüpfung. Konkrete Maßnahmen, die helfen würden:
                                   
                                      Überprüfen und ggf. Zurücksetzen der internen Encryption Keys / Key‑Rotation für den Static Web Apps Authentication Service.
                                      
                                         Überprüfen des Service Principal / Identity Proxy, der für `identity.2.azurestaticapps.net` zuständig ist, und Neuverknüpfung mit der betroffenen SWA.
                                         
                                            Falls erforderlich, Zurücksetzen der Auth‑Konfiguration für die betroffene SWA‑Ressource oder Migration der internen Auth‑State auf einen konsistenten Zustand.
                                            
                                               Kurze Rückmeldung mit den durchgeführten Schritten und, falls nötig, einem Zeitfenster für die Reparatur.
                                               
                                               **Logs / Anhänge (relevant):**
                                               
                                                  Beispiel‑Header‑Auszüge und curl‑Outputs (Datum 21.05.2026) — kann ich auf Anfrage als Text anhängen.
                                                  
                                                     Sign‑in logs zeigen erfolgreiche Redirects bis 15.05.2026; danach fehlschlagende Sessions (Details können wir bei Bedarf bereitstellen).