Häufig gestellte Fragen zur Authentifizierung geschachtelter Apps und veralteter Outlook-Token

Exchange-Benutzeridentitätstoken und Rückruftoken sind veraltet und werden ab Februar 2025 deaktiviert. Es wird empfohlen, Outlook-Add-Ins, die Ältere Exchange-Token verwenden, in die geschachtelte App-Authentifizierung zu verschieben.

Allgemeine häufig gestellte Fragen

Was ist die Authentifizierung geschachtelter Apps (Nested App Authentication, NAA)?

Die Authentifizierung geschachtelter Apps ermöglicht einmaliges Anmelden (Single Sign-On, SSO) für Anwendungen, die in unterstützten Microsoft-Anwendungen wie Outlook geschachtelt sind. Im Vergleich zu vorhandenen voll vertrauenswürdigen Authentifizierungsmodellen und dem On-Behalf-of-Flow bietet NAA eine bessere Sicherheit und mehr Flexibilität in der App-Architektur und ermöglicht die Erstellung umfangreicher, clientgesteuerter Anwendungen. Weitere Informationen finden Sie unter Aktivieren des einmaligen Anmeldens in einem Office-Add-In mit geschachtelter App-Authentifizierung.

Was ist die Zeitleiste zum Herunterfahren von Exchange Online-Legacytoken?

Microsoft beginnt im Februar 2025 damit, ältere Exchange-Onlinetoken zu deaktivieren. Von jetzt bis Februar 2025 sind vorhandene und neue Mandanten nicht betroffen. Wir stellen Tools bereit, mit denen Administratoren Exchange-Token für Mandanten und Add-Ins erneut aktivieren können, wenn diese Add-Ins noch nicht zu NAA migriert wurden. Weitere Informationen finden Sie unter Kann ich Legacytoken wieder aktivieren?

Datum Legacytoken status
Februar 2025 Legacytoken für alle Mandanten deaktiviert. Administratoren können Legacytoken über PowerShell wieder zulassen.
Juni 2025 Legacytoken für alle Mandanten deaktiviert. Administratoren können Legacytoken nicht mehr über PowerShell wieder wiederherstellen und müssen sich für jede Ausnahme an Microsoft wenden.
Oktober 2025 Legacytoken für alle Mandanten deaktiviert. Ausnahmen sind nicht mehr zulässig.

Wann ist NAA für meinen Kanal allgemein verfügbar?

Das Allgemeine Verfügbarkeitsdatum für NAA hängt davon ab, welchen Kanal Sie verwenden.

Datum NAA – Allgemeine Verfügbarkeit (GA)
Oktober 2024 NAA ist allgemein verfügbar im aktuellen Kanal.
November 2024 NAA wird allgemein verfügbar im monatlichen Enterprise-Kanal.
Januar 2025 NAA wird allgemein verfügbar im Semi-Annual Channel.
Juni 2025 NAA wird in Semi-Annual erweiterten Kanal allgemein verfügbar sein.

Microsoft 365-Administratorfragen

Kann ich Legacytoken wieder aktivieren?

Bis Mitte November 2024 führen wir neue Tools über PowerShell für Microsoft 365-Administratoren ein, um ältere Exchange-Token in Ihrem Mandanten zu aktivieren oder zu deaktivieren. Wenn Sie feststellen, dass Sie ältere Exchange-Token erneut aktivieren müssen, können Sie dazu die PowerShell-Cmdlets verwenden. Die Tools melden auch, ob Add-Ins in den letzten 28 Tagen Legacytoken verwenden. Im Juni 2025 werden Legacytoken für Exchange Online deaktiviert, und Sie können sie nicht wieder aktivieren, ohne eine bestimmte ausnahme von Microsoft gewährt. Im Oktober 2025 ist es nicht möglich, Legacytoken Exchange Online zu aktivieren, und sie werden für alle Mandanten deaktiviert. Wir aktualisieren diese häufig gestellten Fragen mit zusätzlichen Informationen, sobald das Tool in allen Mandanten verfügbar ist.

Unabhängige Softwarehersteller (ISVs) aktualisieren ihre Add-Ins, um Entra ID-Token und Microsoft Graph-Bereiche zu verwenden. Wenn das Add-In ein Zugriffstoken anfordert, muss es über die Administrator- oder Benutzereinwilligung verfügen. Wenn der Administrator zustimmt, können alle Benutzer auf dem Mandanten das Add-In für die Bereiche verwenden, die das Add-In benötigt. Andernfalls wird jeder Endbenutzer zur Zustimmung aufgefordert, wenn die Benutzereinwilligung aktiviert ist. Das Abschließen der Administratoreinwilligung bietet eine bessere Erfahrung, da die Benutzer nicht dazu aufgefordert werden.

Eine Möglichkeit für die Zustimmung besteht darin, dass der ISV Ihnen einen Administratoreinwilligungs-URI bereitstellt.

  1. Der Add-In-Entwickler stellt einen Administratoreinwilligungs-URI bereit. Wenn dies nicht in der von ihnen bereitgestellten Dokumentation enthalten ist, müssen Sie sich an diese wenden, um weitere Informationen zu erhalten.
  2. Der Administrator navihiert zum URI für die Administratoreinwilligung.
  3. Der Administrator wird aufgefordert, sich anzumelden und einer Liste von Bereichen zuzustimmen, die für das Add-In erforderlich sind.
  4. Nach Abschluss des Vorgangs leitet der Browser vom ISV zu einer Webseite um, auf der angezeigt werden sollte, dass die Zustimmung erfolgreich war.

Alternativ kann der ISV ein aktualisiertes App-Manifest bereitstellen, das im Rahmen der zentralen Bereitstellung zur Zustimmung des Administrators auffordert. In diesem Szenario werden Sie beim Bereitstellen des aktualisierten App-Manifests zur Zustimmung aufgefordert, bevor die Bereitstellung abgeschlossen werden kann. Es ist kein Administratoreinwilligungs-URI erforderlich.

Wenn das Add-In im Microsoft 365 Store veröffentlicht wird, wird das Update automatisch bereitgestellt, und der Administrator wird aufgefordert, den Bereichen zuzustimmen. Wenn der Administrator nicht zustimmt, können Benutzer das aktualisierte Add-In nicht verwenden.

Stellen Sie sicher, dass Sie keine Features deaktivieren oder Berechtigungen widerrufen, die für das Add-In erforderlich sind. Ein Beispiel finden Sie unter Ändern von Postfachrichtlinieneigenschaften. Das Add-In verwendet delegierte Berechtigungen und hat daher Zugriff auf die gleichen Ressourcen wie der angemeldete Benutzer. Wenn jedoch eine Richtlinie oder Einstellung den Benutzer von einer bestimmten Ressource oder Aktion absperrt, wird das Add-In ebenfalls blockiert.

Gewusst wie Add-In-Updates von einem ISV bereitstellen?

Wenn Sie über ein Add-In verfügen, das Exchange-Legacytoken verwendet, sollten Sie sich an Ihren ISV wenden, um Informationen zu dessen Zeitleiste zu erhalten, um sein Add-In zur Verwendung von NAA zu migrieren. Nachdem der ISV sein Add-In migriert hat, stellt er höchstwahrscheinlich eine URL für die Administratoreinwilligung bereit. Weitere Informationen finden Sie unter Wie funktioniert der Ablauf der Administratoreinwilligung? .

Der ISV kann Ihnen auch ein aktualisiertes App-Manifest zur Bereitstellung über eine zentralisierte Bereitstellung bereitstellen. Während der zentralisierten Bereitstellung werden Sie möglicherweise aufgefordert, allen Microsoft Graph-Bereichen zuzustimmen, die das Add-In erfordert. In diesem Szenario müssen Sie keinen Administratoreinwilligungs-URI verwenden.

Wenn das Add-In über Microsoft AppSource bereitgestellt wird, werden Sie höchstwahrscheinlich aufgefordert, Microsoft Graph-Bereichen zuzustimmen, wenn der ISV Updates für das Add-In ausrollt. Bis Sie zustimmen, können Benutzer auf dem Mandanten die neue Version des Add-Ins nicht mit NAA verwenden.

Welche Add-Ins in meinem organization sind betroffen?

Wir stellen Tools für Administratoren bereit, die die App-ID aller Add-Ins melden, die in den letzten 28 Tagen Ältere Exchange Online-Token verwendet haben. Weitere Informationen finden Sie in diesen häufig gestellten Fragen, wenn die Tools bereit sind. Weitere Informationen finden Sie unter Kann ich Legacytoken wieder aktivieren?.

Add-Ins können die älteren Exchange-Token verwenden, um Ressourcen aus Exchange über die EWS- oder Outlook-REST-APIs abzurufen. Manchmal erfordert ein Add-In Exchange-Ressourcen für einige Anwendungsfälle und nicht für andere, sodass es schwierig ist, herauszufinden, ob das Add-In ein Update erfordert. Es wird empfohlen, sich an Add-In-Entwickler und -Besitzer zu wenden, um sie zu fragen, ob ihr Add-In-Code auf die folgenden APIs verweist.

  • makeEwsRequestAsync
  • getUserIdentityTokenAsync
  • getCallbackTokenAsync

Wenn Sie sich auf einen ISV für Ihr Add-In verlassen, empfehlen wir Ihnen, sich so bald wie möglich an diesen zu wenden, um zu bestätigen, dass er über einen Plan und eine Zeitleiste für das Verschieben von Legacy-Exchange-Token verfügt. ISV-Entwickler sollten sich mit Fragen direkt an ihre Microsoft-Kontakte wenden, um sicherzustellen, dass sie für das Ende der Exchange-Legacytoken bereit sind. Wenn Sie sich auf einen Entwickler in Ihrem organization verlassen, sollten sie diese häufig gestellten Fragen und den Artikel Aktivieren des einmaligen Anmeldens in einem Office-Add-In mithilfe der geschachtelten App-Authentifizierung lesen. Fragen sollten auf der GitHub-Problemwebsite für OfficeDev/office-js gestellt werden.

Sobald der Administrator oder ein Benutzer seine Zustimmung erteilt hat, wird sie im Microsoft Entra Admin Center aufgeführt. Sie können App-Registrierungen mithilfe der folgenden Schritte finden.

  1. Gehen Sie zu https://entra.microsoft.com/#home.
  2. Wählen Sie im linken Navigationsbereich Anwendungen>App-Registrierungen aus.
  3. Wählen Sie auf der Seite App-Registrierungendie Option Alle Anwendungen aus.
  4. Jetzt können Sie nach einer beliebigen App-Registrierung anhand des Namens oder der ID suchen.

Häufig gestellte Fragen zur Migration von Outlook-Add-Ins

Warum migriert Microsoft Outlook-Add-Ins?

Der Wechsel zu Microsoft Graph mit Entra ID-Token ist eine große Verbesserung der Sicherheit für Outlook- und Exchange-Kunden. Entra ID (früher Azure Active Directory) ist ein führender cloudbasierter Identitäts- und Zugriffsverwaltungsdienst. Kunden können Zero Trust-Features wie bedingten Zugriff, MFA-Anforderungen, kontinuierliche Tokenüberwachung, Echtzeitsicherheitsheuristik und mehr nutzen, die bei älteren Exchange-Token nicht verfügbar sind. Kunden speichern wichtige Geschäftsdaten, die in Exchange gespeichert sind, daher ist es wichtig, dass wir sicherstellen, dass diese Daten geschützt sind. Die Migration des gesamten Outlook-Ökosystems zur Verwendung von Entra ID-Token mit Microsoft Graph verbessert die Sicherheit für Kundendaten erheblich.

Muss mein Outlook-Add-In zu NAA migriert werden?

Nein Outlook-Add-Ins müssen keine NAA verwenden, obwohl NAA die beste Authentifizierungserfahrung für Benutzer und den besten Sicherheitsstatus für Organisationen bietet. Wenn Add-Ins keine Exchange-Legacytoken verwenden, sind sie nicht von der Einstellung von Exchange-Token betroffen. Add-Ins, die MSAL.js oder andere SSO-Methoden verwenden, die auf Entra ID basieren, funktionieren weiterhin.

Gewusst wie wissen, ob mein Outlook-Add-In auf Legacytoken basiert?

Wir stellen Tools für Administratoren bereit, die die App-ID aller Add-Ins melden, die in den letzten 28 Tagen Ältere Exchange Online-Token verwendet haben. Weitere Informationen, wenn die Tools bereit sind, finden Sie in diesen häufig gestellten Fragen. Weitere Informationen finden Sie unter Kann ich Legacytoken wieder aktivieren?

Um herauszufinden, ob Ihr Add-In ältere Exchange-Benutzeridentitätstoken und Rückruftoken verwendet, durchsuchen Sie Ihren Code nach Aufrufen der folgenden APIs.

  • makeEwsRequestAsync
  • getUserIdentityTokenAsync
  • getCallbackTokenAsync

Wenn Ihr Add-In eine dieser APIs aufruft, sollten Sie naa übernehmen und stattdessen entra ID-Token für den Zugriff auf Microsoft Graph verwenden.

Welche Outlook-Add-Ins befinden sich im Gültigkeitsbereich?

Viele wichtige Add-Ins befinden sich im Gültigkeitsbereich. Wenn Ihr Add-In EWS oder Outlook REST für den Zugriff auf Exchange Online Ressourcen verwendet, muss es fast sicher von Legacy-Outlook-Token zu NAA migrieren. Wenn Ihr Add-In nur für Lokales Exchange gilt (z. B. Exchange 2019), ist es von dieser Änderung nicht betroffen.

Was geschieht mit meinen Outlook-Add-Ins, wenn ich nicht zu NAA migriert werde?

Wenn Sie Ihre Outlook-Add-Ins nicht zu NAA migrieren, funktionieren diese in Exchange Online nicht mehr wie erwartet. Wenn Exchange-Token deaktiviert sind, blockieren Exchange Online die Ausstellung von Legacytoken. Jedes Add-In, das Legacytoken verwendet, kann nicht auf Exchange Online-Ressourcen zugreifen.

Wenn Ihr Add-In nur lokal funktioniert oder sich Ihr Add-In in einem veralteten Pfad befindet, müssen Sie möglicherweise nicht aktualisieren. Die meisten Add-Ins, die über EWS oder Outlook REST auf Exchange-Ressourcen zugreifen, müssen jedoch migriert werden, um weiterhin wie erwartet zu funktionieren.

Gewusst wie meine Outlook-Add-Ins zu NAA migrieren?

Informationen zur Unterstützung von NAA in Ihrem Outlook-Add-In finden Sie in der folgenden Dokumentation und dem folgenden Beispiel.

Gewusst wie mit den neuesten Anleitungen Schritt halten?

Wir aktualisieren diese häufig gestellten Fragen, sobald neue Informationen verfügbar sind. Wir werden weitere Anleitungen zur Office-Add-Ins-Community und zum M365-Entwicklerblog veröffentlichen. Schließlich können Sie Auf der GitHub-Problemwebsite officeDev/office-js Fragen zu NAA und legacy Exchange Online Token stellen, die veraltet sind. Bitte fügen Sie "NAA" in den Titel ein, damit wir Probleme gruppieren und priorisieren können.

Wenn Sie ein Problem übermitteln, geben Sie die folgenden Informationen an.

  • Outlook-Clientversion.
  • Zielgruppe des Outlook-Releasekanals (für Client).
  • Screenshot des Problems.
  • Die Plattform, auf der das Problem auftritt (Windows, Outlook (neu), Mac, iOS, Android).
  • Sitzungs-ID, bei der das Problem aufgetreten ist.
  • Typ des verwendeten Kontos.
  • Version von msal-browser.
  • Protokolle aus msal-browser.

Fragen zur Problembehandlung für Entwickler

NAA bietet kein einmaliges Anmelden und fordert Benutzer immer wieder auf, sich anzumelden.

Dies kann auftreten, wenn NAA im Outlook-Client nicht verfügbar ist. Überprüfen Sie unter Windows, ob Sie entweder den Betakanal oder den aktuellen Kanal (Vorschau) verwenden. Sie müssen dem Microsoft 365 Insider-Programm beitreten, um zu diesen Kanälen zu wechseln. Eine gute Möglichkeit, um zu überprüfen, ob NAA verfügbar ist, besteht darin, den Anforderungssatz mithilfe des folgenden Codeausschnitts zu überprüfen. Office.context.requirements.isSetSupported("NestedAppAuth")

Gewusst wie weitere Debuginformationen von MSAL und NAA erhalten?

Verwenden Sie den folgenden Code, um Debuginformationen in msalConfig zu aktivieren, wenn Sie die geschachtelte öffentliche Clientanwendung initialisieren. Dadurch werden zusätzliche Details in der Konsole protokolliert.

const msalConfig = {
  auth: {...},
  system: {
    loggerOptions: {
      logLevel: LogLevel.Verbose,
      loggerCallback: (level, message, containsPii) => {
        switch (level) {
          case LogLevel.Error:
            console.error(message);
            return;
          case LogLevel.Info:
            console.info(message);
            return;
          case LogLevel.Verbose:
            console.debug(message);
            return;
          case LogLevel.Warning:
            console.warn(message);
            return;
        }
      },
    }
  }
};