Authentication for Windows 10 Developers


Um Apps mit Authentifizierung unter Windows 10 zu entwickeln gibt es jetzt eine neue API: den WebAccountManager. Hierzu gibt es einen sehr guten Artikel, der den neuen WebAccountManager und im Vergleich hierzu die existierende Active Directory Authentication Library (ADAL) beschreibt.

Eine gute Gelegenheit um sich gleich die “offiziellen” Microsoft-Abkürzungen zu merken:

  • AAD steht für Azure Active Directory Account (also das Konto in der Cloud)
  • MSA steht für Microsoft Account – welcher zuvor als “Live-ID” bezeichnet wurde (und in vielen Dokumentationen und Anwendung noch immer so heißt, aber Microsoft hat bereits angekündigt den Namen nach und nach auszubessern).

Hierzu ein kleiner Rückblick: Unter Windows 8 gab es nur die Unterstützung des Microsoft Accounts (MSA) um auf Cloud-services wie etwa OneDrive zuzugreifen. Jedes Windows-Konto kann in den Konto-Einstellungen mit einem MSA verbunden werden. Diese Unterstützung gibt es nach wie vor auch in Windows 10.

image

Windows 10 besitzt nun eine Integration von Azure Active Directory (AAD) Konten: “Add a work or school account”. Damit werden dem angemeldeten Windows-User Zugriff auf Ressourcen in der Cloud gewährt – seamless, wie man so schön neudeutsch sagt, also ohne zusätzliches Login.

Sehen wir uns nun nach dem Rückblick an, was das für Entwickler bedeutet:
Bereits zuvor wurde mit Windows 8 das Konzept des WebAuthenticationBroker (eine damals neue System-API) eingeführt, die sich um die Authentication und deren Handling kümmert. Damit können Developer – mit etwas Aufwand und mit Kenntnis der Mechanik – aus ihrer native App eine Web Authentication durchführen.

Windows 10 ist das (einzige) Betriebssystem, welches eine OAuth2 Integration direkt in seiner native API unterstützt. Mit anderen Worten: Cool! Und natürlich gibt es eine API dafür, die man für eigene Apps nutzen kann.

Damit sich Entwickler nicht selbst mit OAuth2, den Protokollen und dem Flow befassen muss, bietet Microsoft nun den neuen WebAccountManager an. Die API kümmert sich um alle Protokolle, verwaltet den Token Cache und integriert sich in das Windows System.

Das klingt alles ganz fein. Hier nun gleich der Link zum Original-Artikel von Vittorio:

Develop Windows Universal Apps with Azure AD and the Windows 10 Identity API

Vittorio Luigi Bertocci, Principal PM – und mein persönlicher “Mr. ADAL”, hat diesen tollen Artikel geschrieben, wo er im Detail auf den neuen WebAccountManager  eingeht – und auch gleich auf die Unterschiede zu ADAL hinweist.

Ich empfehle den Original-Artikel zu lesen und möchte hier nur eine sehr kurze Zusammenfassung wiedergeben, um einen Eindruck über die neue Schnittstelle zu liefern.

Der WebAccountManager stellt eine Schnittstelle (programming façade) auf Basis aller WebAuthenticationProviders bereit, die im Windows System installiert sind. Alle Provider, die dem System bekannt sind, können so verwendet werden!

Der WebAccountManager ist von Universal Windows Platform (UWP) Apps verwendbar – und sollte für diesen App-Typ verwendet werden.

Der folgende Code stammt aus dem Original-Artikel um die Vorgangsweise zu zeigen. Für die Verwendung muss zuerst der Provider ausgewählt werden. Danach folgt der Token Request, welcher an den Provider übergeben wird. Retour kommt dann der Token, mit dem man gegen eine Ressource abfragen kann. In Code gegossen sieht der Vorgang etwa so aus:

string tenant = "sometenant.onmicrosoft.com";
string authority = "https://login.microsoftonline.com/" + tenant;
WebAccountProvider wap = await WebAuthenticationCoreManager.FindAccountProviderAsync("https://login.microsoft.com", authority);

Möchte man keine spezifischen AD Tenant auswählen, ist der authority String mit “organizations” zu setzen. Bei Verwendung desselben Codes mit MSA würde man diesen mit “consumers” ersetzen – super easy.

Nun wird der Token mit minimalen Parametern angefordert.
Das funktioniert bei einem vorgegebenem AD Tenant so:

string clientId = "12345b7d-66af-4de9-9ee7-c7b04106bdef";
string resource = "https://graph.windows.net";
WebTokenRequest wtr = new WebTokenRequest(wap, string.Empty, clientId);
wtr.Properties.Add("resource", resource);

War die Anmeldung erfolgreich, kommt nun der Token retour.

WebTokenRequestResult wtrr = await WebAuthenticationCoreManager.RequestTokenAsync(wtr);
if (wtrr.ResponseStatus == WebTokenRequestStatus.Success)
{
accessToken = wtrr.ResponseData[0].Token;
var account = wtrr.ResponseData[0].WebAccount;
var properties = wtrr.ResponseData[0].Properties;
}

Im besten Fall klappt die Authentifizierung und der Erhalt des Tokens ohne Benutzerinteraktion. Falls diese jedoch erforderlich ist (etwa beim ersten Anmelden) oder ein consent (eine Zustimmung für Berechtigungen der App) nötig sind, werden diese zwischengeschaltet. Mit dem Token kann dann weiter gegen eine Ressource gearbeitet werden.

Wichtig ist noch, wann Developer WebAccountManager einsetzen und wann ADAL.

Vittorio empfiehlt die Windows 10 native identity API (den WebAccountManager) immer bei UWP-Apps und Windows Store Apps einzusetzen.

Für alles Andere (Window 7 od. Windows 8.x Apps) ist die Active Directory Authentication Library (ADAL) da. ADAL hat ein paar Unterschiede, etwa werden die Token in einem eigenen Cache gespeichert (logischerweise, da unterschiedliche OS verwendet werden können) und es gibt verschiedene Versionen von ADAL, aktuell ist ADAL Version 3. Achja, natürlich findet ADAL mit spezifischen Bibliotheken für andere OS Verwendung, etwa ADAL iOS und ADAL Android, in Cordova etc.

Source Code Beispiele sind auf GitHub zu finden.
Webcast über WebAccountManager and Azure AD findet ihr auch hier:
Vittorio’s BUILD-session und Karanbir’s BUILD-session

Viel Spaß beim Ausprobieren und Erforschen mit UWP Apps und WebAccountManager!

Um Apps mit Authentifizierung unter Windows 10 zu entwickeln gibt es jetzt eine neue API: den WebAccountManager. Hierzu gibt es einen sehr guten Artikel, der den neuen WebAccountManager und im Vergleich hierzu die existierende Active Directory Authentication Library (ADAL) beschreibt.

Eine gute Gelegenheit um sich gleich die “offiziellen” Microsoft-Abkürzungen zu merken:

  • AAD steht für Azure Active Directory Account (also das Konto in der Cloud)
  • MSA steht für Microsoft Account – welcher zuvor als “Live-ID” bezeichnet wurde (und in vielen Dokumentationen und Anwendung noch immer so heißt, aber Microsoft hat bereits angekündigt den Namen nach und nach auszubessern).

Hierzu ein kleiner Rückblick: Unter Windows 8 gab es nur die Unterstützung des Microsoft Accounts (MSA) um auf Cloud-services wie etwa OneDrive zuzugreifen. Jedes Windows-Konto kann in den Konto-Einstellungen mit einem MSA verbunden werden. Diese Unterstützung gibt es nach wie vor auch in Windows 10.

59

Windows 10 besitzt nun eine Integration von Azure Active Directory (AAD) Konten: “Add a work or school account”. Damit werden dem angemeldeten Windows-User Zugriff auf Ressourcen in der Cloud gewährt – seamless, wie man so schön neudeutsch sagt, also ohne zusätzliches Login.

Sehen wir uns nun nach dem Rückblick an, was das für Entwickler bedeutet:
Bereits zuvor wurde mit Windows 8 das Konzept des WebAuthenticationBroker (eine damals neue System-API) eingeführt, die sich um die Authentication und deren Handling kümmert. Damit können Developer – mit etwas Aufwand und mit Kenntnis der Mechanik – aus ihrer native App eine Web Authentication durchführen.

Windows 10 ist das (einzige) Betriebssystem, welches eine OAuth2 Integration direkt in seiner native API unterstützt. Mit anderen Worten: Cool! Und natürlich gibt es eine API dafür, die man für eigene Apps nutzen kann.

Damit sich Entwickler nicht selbst mit OAuth2, den Protokollen und dem Flow befassen muss, bietet Microsoft nun den neuen WebAccountManager an. Die API kümmert sich um alle Protokolle, verwaltet den Token Cache und integriert sich in das Windows System.

Das klingt alles ganz fein. Hier nun gleich der Link zum Original-Artikel von Vittorio:

Develop Windows Universal Apps with Azure AD and the Windows 10 Identity API

Vittorio Luigi Bertocci, Principal PM – und mein persönlicher “Mr. ADAL”, hat diesen tollen Artikel geschrieben, wo er im Detail auf den neuen WebAccountManager  eingeht – und auch gleich auf die Unterschiede zu ADAL hinweist.

Ich empfehle den Original-Artikel zu lesen und möchte hier nur eine sehr kurze Zusammenfassung wiedergeben, um einen Eindruck über die neue Schnittstelle zu liefern.

Der WebAccountManager stellt eine Schnittstelle (programming façade) auf Basis aller WebAuthenticationProviders bereit, die im Windows System installiert sind. Alle Provider, die dem System bekannt sind, können so verwendet werden!

Der WebAccountManager ist von Universal Windows Platform (UWP) Apps verwendbar – und sollte für diesen App-Typ verwendet werden.

Der folgende Code stammt aus dem Original-Artikel um die Vorgangsweise zu zeigen. Für die Verwendung muss zuerst der Provider ausgewählt werden. Danach folgt der Token Request, welcher an den Provider übergeben wird. Retour kommt dann der Token, mit dem man gegen eine Ressource abfragen kann. In Code gegossen sieht der Vorgang etwa so aus:

string tenant = "sometenant.onmicrosoft.com";
string authority = "https://login.microsoftonline.com/" + tenant;
WebAccountProvider wap = await WebAuthenticationCoreManager.FindAccountProviderAsync("https://login.microsoft.com", authority);

Möchte man keine spezifischen AD Tenant auswählen, ist der authority String mit “organizations” zu setzen. Bei Verwendung desselben Codes mit MSA würde man diesen mit “consumers” ersetzen – super easy.

Nun wird der Token mit minimalen Parametern angefordert.
Das funktioniert bei einem vorgegebenem AD Tenant so:

string clientId = "12345b7d-66af-4de9-9ee7-c7b04106bdef";
string resource = "https://graph.windows.net";
WebTokenRequest wtr = new WebTokenRequest(wap, string.Empty, clientId);
wtr.Properties.Add("resource", resource);

War die Anmeldung erfolgreich, kommt nun der Token retour.

WebTokenRequestResult wtrr = await WebAuthenticationCoreManager.RequestTokenAsync(wtr);
if (wtrr.ResponseStatus == WebTokenRequestStatus.Success)
{
accessToken = wtrr.ResponseData[0].Token;
var account = wtrr.ResponseData[0].WebAccount;
var properties = wtrr.ResponseData[0].Properties;
}

Im besten Fall klappt die Authentifizierung und der Erhalt des Tokens ohne Benutzerinteraktion. Falls diese jedoch erforderlich ist (etwa beim ersten Anmelden) oder ein consent (eine Zustimmung für Berechtigungen der App) nötig sind, werden diese zwischengeschaltet. Mit dem Token kann dann weiter gegen eine Ressource gearbeitet werden.

Wichtig ist noch, wann Developer WebAccountManager einsetzen und wann ADAL.

Vittorio empfiehlt die Windows 10 native identity API (den WebAccountManager) immer bei UWP-Apps und Windows Store Apps einzusetzen.

Für alles Andere (Window 7 od. Windows 8.x Apps) ist die Active Directory Authentication Library (ADAL) da. ADAL hat ein paar Unterschiede, etwa werden die Token in einem eigenen Cache gespeichert (logischerweise, da unterschiedliche OS verwendet werden können) und es gibt verschiedene Versionen von ADAL, aktuell ist ADAL Version 3. Achja, natürlich findet ADAL mit spezifischen Bibliotheken für andere OS Verwendung, etwa ADAL iOS und ADAL Android, in Cordova etc.

Source Code Beispiele sind auf GitHub zu finden.
Webcast über WebAccountManager and Azure AD findet ihr auch hier:
Vittorio’s BUILD-session und Karanbir’s BUILD-session

Viel Spaß beim Ausprobieren und Erforschen mit UWP Apps und WebAccountManager!


Skip to main content