Bei der OAuth 2.0-Authenfizierung die über das Azure Active Directory erfolgt handelt es sich um ein System das von Microsoft angeboten wird. Durch dieses für die Autorisierung benötigte Branchenprotokoll wird dem Nutzer ermöglicht, auf die geschützten Ressourcen einen eingeschränkten Zugriff zu erhalten. Das System wurde konzipiert für die HTTP (Hypertexte Transfer-Protokoll) Verwendung und hat die Aufgabe, die Rollen des Clients vom Besitzer der Ressourcen zu trennen.
So funktioniert die OAuth-Authenfizierung
Wenn OAuth 2.0 zum Einsatz kommt, dann werden die Ressourcen über einen Zugriff des Clients angefordert. Diese werden im Ressourcenserver verwaltet und über den Ressourcenbesitzer gesteuert. Mit Genehmigung des Ressourcenbesitzers gibt der Server dann einen Zugriffstoken an den Client, Dieser kann hiermit auf die gehosteten und geschützten Ressourcen auf dem Server zurückgreifen.
Hierbei steht OAuth 2.0 in direkter mit OIDC (OpenID Connect). Allerdings handelt es sich hierbei um eine Autorisierungsebene auf der Basis von OAuth 2.0 und ist mit dem vorherigen System OAuth 1.0 nicht kompatibel. Allerdings unterstützt das Azure AD (Azure Active Directory) alle Flows von OAuth 2.0.
Das System ist in die folgenden Komponenten aufgeteilt:
Benutzer
Bei dem Benutzer handelt es sich meist um den Besitzer der Ressourcen. Dieser fordert von der Webanwendung der Web-App einen Dienst an. So kann er den Clients die Möglichkeit bieten, dass diese einen Zugriff auf seine Ressourcen haben. Er kann diesen Zugriff aber auch verweigern. Wenn zum Beispiel eine App die APO aufrufen will, um die Benutzer E-Mail zu erhalten, kann der Benutzer dies entweder zulassen oder verweigern.
Webbrowser
Der Benutzer agiert hierbei mit dem Webbrowser OAuth-Client
Web-App
Bei der oben bereits erwähnten Web-App handelt es sich um den Ressourcenserver, also den Platz, an dem die Daten und Ressourcen des Benutzers abgelegt werden. Dieser steht in enger Zusammenarbeit mit dem Autorisierungsserver, der die Autorisierung und die Authentifizierung der Clients übernimmt, die auf die Ressourcen zurückgreifen wollen.
Azure AD
Bei diesem Autorisierungsserver handelt es sich um das Azure AD: Dieser wird meist auch als Identity Provider IdP (Identitätsanbieter) bezeichnet. Auf sichere Weise wird hier alles verarbeitet, was mit den Benutzer-Informationen zusammenhängt. Vor allem auch die Vertrauensstellungen und dessen Zugriff. Zudem ist das Azure AD dafür zuständig, dass die Token ausgegeben werden, über die ein Ressourcen-Zugriff widerrufen oder gewährt wird.
Token
Bei den Token oder Bearertoken handelt es um das System das verwendet wird, um einem Dienst, Host oder Benutzer die Gewährleistung zu bieten, dass der Zugriff eines Clients auf die zur Verfügung gestellten Ressourcen vorab authentifiziert und überprüft wird. Auf der Microsoft Identity Plattform werden die Bearertoken als JSON-Webtoken formatiert.
Hier wird in drei Arten von Sicherheitstoken unterschieden:
Zugriffstoken werden dem Client von dem Autorisierungsserver ausgestellt. Diese werden vom Client an den Ressourcenserver übergeben. Hierin sind die Berechtigungen enthalten, die der Autorisierungsserver dem Client ausgestellt hat.
Vom Autorisierungsserver werden ebenfalls die ID-Token für die Anwendung des Clients ausgestellt. Um Informationen über die Benutzer zu erhalten, verwenden die Clients diese Token.
Die Aktualisierungstoken werden vom Client verwendet, wenn er neue ID- und Zugriffstoken über den Autorisierungsserver anfordert. Diese Token sind daher auch nur für den Zugriff auf den Autorisierungsserver vorgesehen und der Code behandelt den Zeichenfolgeinhalt so, dass der Zugriff auch gewährleistet werden kann.
App-Registrierung
Die heruntergeladene Client-App muss den Sicherheitstoken vertrauen können. Daher besteht der erste Schritt hier das diese in dem Azure AD registriert wird. Bei der Registrierung in der App werden die folgenden Einstellungen verwendet:
Client- oder Anwendungs-ID wird der App von der Microsoft Identity Plattform zugewiesen. Die ID ist in den Sicherheitstoken enthalten und identifiziert die App auf der Identity Plattform eindeutig.
Die Umleitungs-URL wird dann vom Autorisierungsserver verwendet, um die mobile App oder den Webbrowser an ein anderes Ziel weiterzuleiten. Allerdings werden diese Umleitungs-URls nicht von allen Clienttypen verwendet. Dies geschieht in der Regel auch immer dann, wenn der Autorisierungsserver den Endbenutzer authentifiziert hat.
Daneben enthält eine App-Registrierung auch alle Informationen zu den Autorisierungs- und Authentifizierungs-Endpunkten die Abruf-Code von Zugriffs- und ID-Token verwendet werden.
Endpunkte
Zwei sehr oft verwendete Endpunkte sind der Token-Endpunkt und der Autorisierungs-Endpunkt. Diese werden in der App generiert, wenn diese in das Azure AD konfiguriert und registriert wird. Welche Codes in der App verwendet werden, hängt hierbei auch immer von den Kontotypen oder auch Identitäten sowie vom Typ der Anwendung , die unterstützt werden sollen.
Die Anwendungstypen auf der Identity Plattform von Microsoft
Eine Vielzahl von modernen App-Architekturen werden von der Microsoft Identity Plattform unterstützt. Diese basieren alle auf den bei OpenID Connect und OAuth 2.0 branchenüblichen Standardprotokollen. Hierbei sind als erstes die folgenden Grundlagen zu beachten:
Jede App, die auf der Microsoft IP verwendet wird, muss vorab im Azure AD registriert werden. Hierbei werden eine Anwendungs- oder Client-ID, eine Umleitungs-URl sowie andere Kontotypen erfasst.
Nachdem die App registriert wurde, beginnt die Kommunikation mit der Microsoft ID. Dies geschieht über Anforderungen, die an den Endpunkt gesendet werden. Folgende Anforderungen an die Endpunkte können hierbei auch selbst erstellt werden:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
Die von Microsoft ID unterstützten verschiedenen Apps und Zugriffe
Von der Microsoft ID werden verschiedene Zugriffe und Apps unterstützt. So gehören hierzu JavaScript oder auch Single-Page genannte Apps. Für diese Single-Page-Apps wird von Microsoft empfohlen, den Authorisierungscodeflow zu nutzen anstatt des früher verwendeten implizierten Flusses, um eine bessere Sicherheit zu gewährleisten.
Daneben werden auch die verschiedenen Web-Apps unterstützt. Hierbei handelt es sich um Node, Python, Ruby, Java, PHP und .NET. Über Open ID Connect wird ein ID-Token an die Web-App gesendet, das die Identität des Benutzers überprüft und Informationen über diesen bereithält. Wenn eine einfache Anmeldung an die Webserver-App gesendet wird, kann es möglicherweise zu einem weiteren Zugriff auf einen anderen Dienst kommen. Dann kommt es zu einem kombinierten OAuth 2.0 und OpenID Connect-Vorgang bei dem der OAuth 2.0 Autorisierungscodefluss Anwendung findet
Für den Schutz von Webdiensten ist die Microsoft ID ebenfalls zuständig. So können Web-APIs in vielen verschiedenen Sprachen und auf verschiedenen Plattformen implementiert werden. Auch über Azure Functions ist dies mit den HTTP-Triggern möglich. Hierbei werden die Zugriffstoken der Clients überprüft. Im Code sind hier zum Beispiel Informationen zu Ansprüchen des Clients enthalten. Die Zugriffstoken können hierbei von jedem App-Typ empfangen werden. Hierzu gehören sowohl Desktop- als auch mobile Apps, Single-Page-App, Webserver-Apps, serverseitiger Deamons und auch von anderen Web-APis.
