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

Hallo,
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.

Ich habe die App schon mehrfach neu veröffentlicht. Ich habe bereits auch schon eine weiteres Static Web App angelegt und beobachte das selbe verhalten. Ich vermute es liegt an EntraId. Die versuche habe ich auch in einem Inkognito Fenster gemacht - selbe Beobachtung. Ich habe schon Stunden mit Copilot verbracht um eine Lösung zu finden - jedoch vergebens.

Ich habe auch den Eindruck die App registriert sich nicht im EntraId - nur als Anmerkung.
Das ging bereits alles schon mal, wo das SSO noch von der Static Web App im Free Plan unterstützt wurde. Es hat nie perfekt funktioniert - aber es ging. Vielleicht waren das Konfigurationsprobleme.
Da sich das jetzt geändert hat habe ich die Static Web App jetzt auch auf Standard gehievt - und es geht dennoch nicht.

Folgend ist eine detaillierte Analyse welche ich mit Copilot zusammen erstellt habe.

Ich würde mich wirklich freuen, wenn sich jemand dieser Sache annimmt, da es mein Projekt schon seit längerem blockt und ich einfach (in meinen Augen) umsonst bezahle.

Detaillierte Symptome / Beobachtungen:

• GET https://polite-beach-{meineapp}.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-{meineapp}.azurestaticapps.net/.auth/me → 200 OK mit JSON { "clientPrincipal": null }.
• GET https://polite-beach-{meineapp}.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).

Kontakt / Ansprechpartner:

• Sven Gutmann (svengutmann@...) — erreichbar für Rückfragen und Live‑Tests.
• Ich kann bei Bedarf temporäre Debug‑Logs oder weitere curl‑Outputs liefern.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-{meineapp}.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-{meineapp}.azurestaticapps.net/.auth/me → 200 OK mit JSON { "clientPrincipal": null }.
      • GET https://polite-beach-{meineapp}.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-{meineapp}.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-{meineapp}.azurestaticapps.net/.auth/me → 200 OK mit JSON { "clientPrincipal": null }.
    • GET https://polite-beach-{meineapp}.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). Kontakt / Ansprechpartner:
    • Sven Gutmann (svengutmann@...) — erreichbar für Rückfragen und Live‑Tests.
    • Ich kann bei Bedarf temporäre Debug‑Logs oder weitere curl‑Outputs liefern.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-{meineapp}.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-{meineapp}.azurestaticapps.net/.auth/me → 200 OK mit JSON { "clientPrincipal": null }.
      • GET https://polite-beach-{meineapp}.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.
  
  ```yaml
    `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.
  
  ```sql
    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.
  
  ```yaml
    Ü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).