Single-Page-Webanwendungen

Einzelseitenanwendungen (Single Page Applications, SPAs) sind in der Regel als JavaScript-Präsentationsebene (Front-End) strukturiert, die im Browser ausgeführt wird, und ein Web-API-Back-End, das auf einem Server ausgeführt wird und die Geschäftslogik der Anwendung implementiert. Weitere Informationen zur impliziten Autorisierungserteilung und zur Entscheidung, ob es für Ihr Anwendungsszenario geeignet ist, finden Sie unter Grundlegendes zum impliziten OAuth2-Genehmigungsfluss in Azure Active Directory.

Wenn sich der Benutzer anmeldet, verwendet das JavaScript-Front-End die Active Directory-Authentifizierungsbibliothek für JavaScript (ADAL.JS) und den impliziten Autorisierungsgrant, um ein ID-Token (id_token) von Azure AD abzurufen. Das Token wird zwischengespeichert, und der Client fügt es an die Anforderung als Bearertoken an, wenn Aufrufe an das Web-API-Back-End ausgeführt werden, das mithilfe der OWIN-Middleware gesichert wird.

Diagramm

Protokollfluss

1. Der Benutzer navigiert zur Webanwendung.
2. Die Anwendung gibt das JavaScript-Front-End (Präsentationsebene) an den Browser zurück.
3. Der Benutzer initiiert die Anmeldung, z. B. durch Klicken auf einen Anmeldelink. Der Browser sendet einen GET an den Azure AD-Autorisierungsendpunkt, um ein ID-Token anzufordern. Diese Anforderung enthält die Anwendungs-ID und die Antwort-URL in den Abfrageparametern.
4. Azure AD überprüft die Antwort-URL anhand der registrierten Antwort-URL, die im Azure-Portal konfiguriert wurde.
5. Der Benutzer meldet sich auf der Anmeldeseite an.
6. Wenn die Authentifizierung erfolgreich ist, erstellt Azure AD ein ID-Token und gibt es als URL-Fragment (#) an die Antwort-URL der Anwendung zurück. Bei einer Produktionsanwendung sollte diese Antwort-URL HTTPS sein. Das zurückgegebene Token enthält Ansprüche über den Benutzer und Azure AD, die von der Anwendung zum Überprüfen des Tokens erforderlich sind.
7. Der im Browser ausgeführte JavaScript-Clientcode extrahiert das Token aus der Antwort, um Aufrufe an das Web-API-Back-End der Anwendung zu sichern.
8. Der Browser ruft das Web-API-Back-End der Anwendung mit dem ID-Token im Autorisierungsheader auf. Der Azure AD-Authentifizierungsdienst gibt ein ID-Token aus, das als Bearertoken verwendet werden kann, wenn die Ressource mit der Client-ID übereinstimmt (in diesem Fall gilt dies, da die Web-API das eigene Back-End der App ist).

Codebeispiele

Sehen Sie sich die Codebeispiele für Einzelseitenanwendungsszenarienan. Achten Sie darauf, regelmäßig nachzusehen, da oft neue Beispiele hinzugefügt werden.

App-Registrierung

• Einzelner Mandant – Wenn Sie nur für Ihre Organisation eine Anwendung erstellen, muss sie mithilfe des Azure-Portals im Verzeichnis Ihres Unternehmens registriert werden.
• Multi-Tenant - Wenn Sie eine Anwendung erstellen, die von Benutzern außerhalb Ihrer Organisation verwendet werden kann, muss sie nicht nur im Verzeichnis Ihres Unternehmens, sondern auch im Verzeichnis jeder Organisation registriert werden, die die Anwendung verwenden wird. Um Ihre Anwendung in ihrem Verzeichnis verfügbar zu machen, können Sie einen Registrierungsprozess für Ihre Kunden einschließen, mit dem sie Ihrer Anwendung zustimmen können. Wenn sie sich für Ihre Anwendung registrieren, wird ihnen ein Dialogfeld mit den berechtigungen angezeigt, die die Anwendung benötigt, und dann die Option zur Zustimmung. Je nach den erforderlichen Berechtigungen ist möglicherweise ein Administrator in der anderen Organisation erforderlich, um die Zustimmung zu erteilen. Wenn der Benutzer oder Administrator zustimmt, wird die Anwendung in ihrem Verzeichnis registriert.

Nach der Registrierung der Anwendung muss sie für die Verwendung des impliziten OAuth 2.0-Genehmigungsprotokolls konfiguriert werden. Dieses Protokoll ist standardmäßig für Anwendungen deaktiviert. Um das implizite OAuth2-Genehmigungsprotokoll für Ihre Anwendung zu aktivieren, bearbeiten Sie das Anwendungsmanifest aus dem Azure-Portal, und legen Sie den Wert "oauth2AllowImplicitFlow" auf "true" fest. Weitere Informationen finden Sie unter Anwendungsmanifest.

Token-Ablauf

Die Verwendung von ADAL.js hilft bei:

• Aktualisieren eines abgelaufenen Tokens
• Anfordern eines Zugriffstokens zum Aufrufen einer Web-API-Ressource

Nach einer erfolgreichen Authentifizierung schreibt Azure AD ein Cookie im Browser des Benutzers, um eine Sitzung einzurichten. Beachten Sie, dass die Sitzung zwischen dem Benutzer und Azure AD (nicht zwischen dem Benutzer und der Webanwendung) vorhanden ist. Wenn ein Token abläuft, verwendet ADAL.js diese Sitzung, um im Hintergrund ein anderes Token abzurufen. ADAL.js verwendet einen ausgeblendeten iFrame zum Senden und Empfangen der Anforderung mithilfe des impliziten OAuth-Genehmigungsprotokolls. ADAL.js können denselben Mechanismus verwenden, um still und leise Zugriffstoken für andere Web-API-Ressourcen abzurufen, die von der Anwendung aufgerufen werden, solange diese Ressourcen die Cross-Origin-Ressourcenfreigabe (CORS) unterstützen, im Verzeichnis des Benutzers registriert sind und alle erforderlichen Zustimmungen vom Benutzer während der Anmeldung erteilt wurden.

Nächste Schritte

• Weitere Informationen zu anderen Anwendungstypen und Szenarien
• Erfahren Sie mehr über die Azure AD -Authentifizierungsgrundlagen