Freigeben über

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

  • Artikel

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 ist 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.

Sind COM-Add-Ins von der Einstellung von Legacytoken Exchange Online betroffen?

Es ist sehr unwahrscheinlich, dass COM-Add-Ins von der Veraltetkeit von Legacytoken Exchange Online betroffen sind. Outlook-Web-Add-Ins sind in erster Linie betroffen, da sie Office.js APIs verwenden können, die auf Exchange-Token basieren. Weitere Informationen finden Sie unter Gewusst wie, ob mein Outlook-Add-In auf Legacytoken basiert. Die Exchange-Token werden für den Zugriff auf Exchange-Webdienste (EWS) oder Outlook-REST-APIs verwendet, die ebenfalls veraltet sind. Wenn Sie vermuten, dass ein COM-Add-In betroffen ist, können Sie es testen, indem Sie es auf einem Mandanten mit deaktivierten Exchange-Token verwenden. Weitere Informationen finden Sie unter Aktivieren oder Deaktivieren von Legacytoken Exchange Online.

Microsoft 365-Administratorfragen

Kann ich Exchange Online Legacytoken wieder aktivieren?

Ja, es gibt PowerShell-Befehle, mit denen Sie Legacytoken in jedem Mandanten aktivieren oder deaktivieren können. Weitere Informationen zum Aktivieren oder Deaktivieren von Legacytoken finden Sie unter Aktivieren oder Deaktivieren von Legacytoken Exchange Online. Wenn Sie die Befehle verwenden, um Legacytoken Exchange Online zu aktivieren, werden sie im Februar 2025 nicht deaktiviert. Sie bleiben bis Juni 2025 oder bis Sie die Tools verwenden, um sie zu deaktivieren.

Im Juni 2025 werden Legacytoken deaktiviert, und Sie können sie ohne eine bestimmte von Microsoft gewährte Ausnahme nicht wieder aktivieren. Im Oktober 2025 ist es nicht möglich, Legacytoken zu aktivieren, und sie werden für alle Mandanten deaktiviert. Wir aktualisieren diese häufig gestellten Fragen mit zusätzlichen Informationen, sobald das Tool 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 haben eine Liste aller Outlook-Add-Ins veröffentlicht, die im Microsoft Store veröffentlicht wurden und ab Oktober 2024 Legacytoken verwenden. Weitere Informationen zur Verwendung der Liste und zum Erstellen eines Berichts von Outlook-Add-Ins, die möglicherweise Legacytoken verwenden, finden Sie unter Suchen von Outlook-Add-Ins, die Legacytoken Exchange Online verwenden. Außerdem arbeiten wir an Berichtstools, um die Nachverfolgung von Add-Ins mithilfe von Legacytoken zu vereinfachen. Wir hoffen, dass die Berichtstools Anfang 2025 verfügbar sind.

Add-Ins können die Legacytoken verwenden, um Ressourcen von 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.

Gibt es eine Liste von Herausgebern, die ihre Add-Ins aktualisiert haben?

Einige häufig verwendete Outlook-Add-In-Herausgeber haben ihre Add-Ins bereits wie unten aufgeführt aktualisiert.

Wenn der Herausgeber sein Manifest aktualisiert hat und das Add-In über den Microsoft Store bereitgestellt wird, werden Sie als Administrator aufgefordert, die Updates zu aktualisieren und bereitzustellen. Wenn der Herausgeber sein Manifest aktualisiert hat und das Add-In über die zentrale Bereitstellung bereitgestellt wird, müssen Sie das neue Manifest als Administrator bereitstellen. In einigen Fällen verfügt der Herausgeber möglicherweise über einen Administratoreinwilligungs-URI, den Sie verwenden müssen, um neuen Bereichen für das Add-In zuzustimmen. Wenden Sie sich an Herausgeber, wenn Sie weitere Informationen zum Aktualisieren eines Add-Ins benötigen.

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?

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.

Entwicklerfragen

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;
        }
      },
    }
  }
};

Gewusst wie das ID-Token überprüfen oder den Benutzer authentifizieren?

Mithilfe von Exchange-Token können Sie das ID-Token überprüfen und verwenden, um den Benutzer für den Zugriff auf Ihre eigenen Ressourcen zu autorisieren. Weitere Informationen finden Sie unter Authentifizieren eines Benutzers mit einem Identitätstoken für Exchange. MSAL mit Entra ID-Token verwendet diesen Ansatz jedoch nicht.

Wenn Sie ein Token über MSAL anfordern, werden immer drei Token zurückgegeben.

Token Zweck Scopes
ID-Token Stellt dem Client (Aufgabenbereich) Informationen zum Benutzer bereit. profile und openid
Aktualisierungstoken Aktualisiert die ID und zugriffstoken, wenn sie ablaufen. offline_access
Zugriffstoken Authentifiziert den Benutzer für bestimmte Bereiche für eine Ressource, z. B. Microsoft Graph. Alle Ressourcenbereiche, z user.read. B. .

MSAL gibt immer diese drei Token zurück. Sie fordert , profileopenidund offline_access als Standardbereiche an, auch wenn Ihre Tokenanforderung diese nicht enthält. Dadurch wird sichergestellt, dass die ID und Aktualisierungstoken angefordert werden. Sie müssen jedoch mindestens einen Ressourcenbereich einschließen, z user.read . B. damit Sie ein Zugriffstoken erhalten. Andernfalls kann die Anforderung fehlschlagen.

Die Übergabe des ID-Tokens über einen Netzwerkaufruf, um den Zugriff auf einen Dienst zu aktivieren oder zu autorisieren, ist ein Sicherheits-Antimuster. Das Token ist nur für den Client (Aufgabenbereich) vorgesehen, und es gibt keine Möglichkeit für den Dienst, das Token zuverlässig zu verwenden, um sicherzustellen, dass der Benutzer über autorisierten Zugriff verfügt. Weitere Informationen zu ID-Tokenansprüchen finden Sie unter https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference.

Es ist sehr wichtig, dass Sie immer ein Zugriffstoken für Ihre eigenen Dienste anfordern. Das Zugriffstoken enthält auch die gleichen ID-Ansprüche, sodass Sie das ID-Token nicht übergeben müssen. Erstellen Sie stattdessen einen benutzerdefinierten Bereich für Ihren Dienst. Weitere Informationen zu App-Registrierungseinstellungen für Ihre eigenen Dienste finden Sie unter Geschützte Web-API: App-Registrierung. Wenn Ihr Dienst das Zugriffstoken empfängt, kann er es überprüfen und ID-Ansprüche aus dem Zugriffstoken verwenden.

Verwandte Inhalte