Wie überprüfe ich ID_Token und Access_Token für eigene Anwendungen in Azure?

 In Firmen-News, Security, Top Stories

Übersicht und Zielstellung

Viele Unternehmen nutzen Microsoft Azure. Azure steht an erster Stelle für die Verwaltung der Identitäten und deren Authentifizierung und Autorisierung. Microsoft bietet eine Vielzahl von vorkonfigurierten Apps an, die Sie als so genannte Enterprise Apps in Azure registrieren können. Danach können die Endanwender diese entsprechend ihrer Berechtigungen nutzen.

Dabei wird für die Authentifizierung und Autorisierung entweder SAML 2.0 oder OAuth2 (manchmal auch in Verbindung mit OpenID Connect) genutzt. All diese Optionen haben gemeinsam, dass nach der Authentifizierung Token ausgestellt werden, welche mindestens Informationen zu dem angemeldeten Benutzer in Form von Claims mit sich tragen. Die Sicherheit der so übertragenen Anmeldeinformationen ist von großer Bedeutung, damit kein unbefugter Zugriff erfolgen kann. Die Auswertung und Überprüfung der Tokens mit den Anmelde- und Zugriffsinformationen obliegt dem Entwickler der Apps. Konfigurieren Sie Enterprise Apps in Azure, vertrauen Sie diesbezüglich also dem Anbieter der Software. Entwickeln Sie jedoch selber Anwendungen, welche Sie in Azure registrieren, sind Sie auch für die Überprüfung der Tokens verantwortlich. Dieser Artikel beschreibt den Vorgang der Überprüfung anhand eines OAuth2 Tokens.

Microsoft stellt eine Vielzahl von Beispielen zur Authentifizierung bereit. Vorausgesetzt wird, Sie verwenden eine solche App und haben sich erfolgreich an Azure angemeldet. Alternativ dazu können Sie Tools (z. B. Postman) verwenden, um sich an Azure anzumelden und einen ID_Token oder / und einen Access_Token zu bekommen. Dann können Sie jetzt diesen Token verwenden, um mit dem hier vorgestellten Prozedere die Gültigkeit des Tokens nachzuvollziehen.

Entwickeln Sie Ihre eigene App, sind die gleichen Überprüfungen unabdingbarer Bestandteil.

Die Token sind in drei Teile aufgeteilt: Header, Payload und (optional) die Signatur. Alle Teile sind Base64 codiert und im Token durch einen Punkt („.“) voneinander getrennt. Header und Payload folgen der JSON Notation. Die wichtigsten Bestandteile von Header und Payload sind nachfolgend beschrieben:

Header:

Es sind nur die Felder mit Bedeutung für dieses Dokument kommentiert. Es kann weitere geben.

{

„typ“: „JWT“,

„alg“: „RS256“,

„kid“: „-sxMJMLCIDWMTPvZyJ6tx-CDxw0“

„x5t“: „-sxMJMLCIDWMTPvZyJ6tx-CDxw0“

}

 

Payload

Es sind nur die Felder mit Bedeutung für dieses Dokument kommentiert. Es kann weitere geben.

{

„aud“: „api://3d8957c5-xxxx-yyyy-zzzz-da285559c21f“,

„iss“: „https://sts.windows.net/<TenantID>/“,

„iat“: 1549449768,

„nbf“: 1549449768,

„exp“: 1549453668,

„scp“: „General.Access“,

„name“: „MarcS“,

„upn“: „Henry@Schleichardt.onmicrosoft.com“,

}

 

Das zu dem Beispiel passende Token schaut wie folgt aus:

(Header rot, Payload schwarz, Signatur grün [gekürzt])

eyAgInR5cCI6ICJKV1QiLCAgImFsZyI6ICJSUzI1NiIsICAieDV0IjogIi1zeE1KTUxDSURXTVRQdlp5SjZ0eC1DRHh3MCIsICAia2lkIjogIi1zeE1KTUxDSURXTVRQdlp5SjZ0eC1DRHh3MCJ9.eyAgImF1ZCI6ICJhcGk6Ly8zZDg5NTdjNS14eHh4LXl5eXktenp6ei1kYTI4NTU1OWMyMWYiLCAgImlzcyI6ICJodHRwczovL3N0cy53aW5kb3dzLm5ldC83YWE2NmNlZC1hYWFhLWJiYmItY2NjYy0yOWE3YjljNGIyOWQvIiwgICJpYXQiOiAxNTQ5NDQ5NzY4LCAgIm5iZiI6IDE1NDk0NDk3NjgsICAiZXhwIjogMTU0OTQ1MzY2OCwgICJzY3AiOiAiR2VuZXJhbC5BY2Nlc3MiLCAgIm5hbWUiOiAiTWFyY1MiLCAgICAidXBuIjogIkhlbnJ5QFNjaGxlaWNoYXJkdC5vbm1pY3Jvc29mdC5jb20iLH0g.D8ZLDJ0EquK2FMPnQubgCTswTAdC4qO-…._xcpLYlSrLtclJ_Fxd0Z-6gQ

 

Überprüfung der Claims im Token

Warum müssen die Felder in den Tokens geprüft werden und wie?

Als Anwendungsbetreiber bekommen Sie einen Token überreicht, der dem Anwender oder einem Service Zugriff auf die Anwendung und deren Daten und Prozesse erlauben soll.

Deshalb prüfen Sie zunächst:

# Bezeichner im Token Frage Beschreibung Aufgabe
1. aud Ist das Token für Ihre Anwendung gedacht? In dem Feld steht ein fixer Wert, den Sie als Anwendungsbetreiber bei der Registrierung der Anwendung in Azure angegeben haben.

Prüfen Sie also, ob der Wert im Token mit Ihrem Wert übereinstimmt.

Der Wert ist ein konstanter String.

2. iss Ist das Token von einem Aussteller, dem Sie vertrauen? Der Aussteller in unserem Fall ist Azure. Der Wert setzt sich zusammen aus dem Pfad zum Security Token Service in Azure und Ihrer Tenant ID in Form einer GUID.
https://sts.windows.net//
3. iat Wann wurde das Token ausgestellt? Ausstellungsdatum dieses Tokens im UNIX Format (Sekunden seit dem 01.01.1970) Ist es ein valides Datum. Wenn es z. B. in der Zukunft liegt, kann das Token nicht gültig sein.
4. nbf Ab wann gilt das Token? UNIX Format (Sekunden seit dem 01.01.1970) Nur wenn das Datum in der Vergangenheit liegt, kann das Token gültig sein.
5. exp Bis wann gilt das Token? UNIX Format (Sekunden seit dem 01.01.1970) Nur wenn das Datum in der Zukunft liegt, kann das Token gültig sein.
6. upn Ist ein Anmeldename vorhanden? Ihre App benötigt eine eindeutige Zuordnung von Anmeldenamen zur Person oder zu einem Prozess, die bzw. der zugreifen möchte.
7. scp Sind Berechtigungen in Ihrer App zu differenzieren? Im Scope sind die Berechtigungen, die der Anwender in Ihrer Anwendung aufgrund seiner Anmeldung bekommen soll, gespeichert.

Anmerkung: Die verschiedenen Datumsangaben (iat, nbf, exp) müssen natürlich im Zusammenhang betrachtet werden.

Überprüfung der Signatur

Die Token werden im Internet zwischen den Endpunkten für Authentifizierung und Autorisierung in Azure und Ihrer Anwendung per SSL verschlüsselt übertragen. Trotzdem müssen sie vor Veränderung auf dem Transit geschützt werden. Dazu werden Header und Payload digital signiert. Die angehängte Signatur kann beim Empfänger geprüft werden.

Damit diese Funktion ausgeführt werden kann, sind wichtige Informationen im Header enthalten:

# Bezeichner im Token Erklärung
1. typ Bezeichner, der den Tokentyp klärt. JSON in diesem Fall.
2. alg Signaturalgorithmus, der bei der Erstellung der digitalen Signatur verwendet wurde.
3. kid Ein Index, der auf den verwendeten Schlüssel verweist.

In Azure werden für die Signatur von Schlüsseln in der Regel mehr als ein Schlüssel bereitgestellt. Das stellt sicher, dass bei Ablauf oder Kompromittierung eines Schlüssels, bereits wenigstens ein neuer Schlüssel bekannt ist, welcher noch verwendet werden kann.

Azure veröffentlicht im Fall von OpenID Connect und OAuth2 die öffentlichen Anteile der aktuellen Signaturschlüssel gemäß der OAuth2 Spezifikation unter folgendem Link:

https://login.microsoftonline.com/{<TenentID>}/discovery/v2.0/keys

Unter diesem Link sind alle aktuell verwendeten öffentlichen Signaturschlüssel abrufbar. Sie werden dort in einem Dokument veröffentlicht, dessen Format wiederum der JSON Notation folgt.

Anmerkungen:

  • Die Signaturen sind wegen der besseren Lesbarkeit im nachfolgenden Beispiel gekürzt.
  • Es sind nur die für dieses Beispiel notwendigen Felder übernommen.

{

„keys“: [{

„kty“: „RSA“,

„use“: „sig“,

„kid“: „-sxMJMLCIDWMTPvZyJ6tx-CDxw0“,

„x5t“: „-sxMJMLCIDWMTPvZyJ6tx-CDxw0“,

„x5c“: [„MIIDBTCCAe2gAwIBAgIQKOfEJNDyDplB…K+o5hFOOMK7y/F5r467jHez“],

„issuer“: „https://login.microsoftonline.com/<TenantID>/v2.0“

}, {

„kty“: „RSA“,

„use“: „sig“,

„kid“: „N-lC0n-9DALqwhuHYnHQ63GeCXc“,

„x5t“: „N-lC0n-9DALqwhuHYnHQ63GeCXc“,

„x5c“: [„MIIDBTCCAe2gAwIBAgIQP8sUV4hf2Zx…NcTnHJeRV1“],

„issuer“: „https://login.microsoftonline.com/<TenantID>/v2.0“

}, {

„kty“: „RSA“,

„use“: „sig“,

„kid“: „M6pX7RHoraLsprfJeRCjSxuURhc“,

„x5t“: „M6pX7RHoraLsprfJeRCjSxuURhc“,

„x5c“: [„MIIC8TCCAdmgAwIBAgIQfEWlTVc1uINE….MwaVt5432GA==“],

„issuer“: „https://login.microsoftonline.com/<TenantID>/v2.0“

}]

}

 

Wie Sie sehen, wurden zum Zeitpunkt der Erstellung dieses Dokumentes drei Schlüssel veröffentlicht.

# Bezeichner im Token Erklärung Verwendung
1. kty Key Type, in dem Fall ist es ein Schlüssel basierend auf den RSA Algorithmen Wird benötigt, damit Sie bei der Prüfung der Signatur den richtigen Algorithmus verwenden.
2. use Schlüsselverwendung ist die digitale Signatur
3. kid Key ID Der eindeutige Index für diesen Schlüssel in der aktuellen Sammlung. Steht im direkten Zusammenhang mit dem Feld „kid“ im Header des Token.
4. x5t Gleiche Verwendung wie kid
5. X5c Der öffentliche Schlüssel Der Schlüssel mit der zum Header passenden „kid“ kann zur Überprüfung der Signatur herangezogen werden.

Der letzte Schritt der Überprüfung eines Tokens ist die Überprüfung der Signatur.

Microsoft stellt mit ADAL und MSAL zwei Bibliotheken für unterschiedliche Programmiersprachen und Autorisierungsendpunkte in Azure bereit. Für die Überprüfung eines Tokens kann im Umfeld von .NET Entwicklung die JwtSecurityTokenHandler Class verwendet werden.

https://docs.microsoft.com/en-us/previous-versions/visualstudio/dn464181(v%3Dvs.114)

Sie unterstützt speziell das Erzeugen und Prüfen von Tokens. Für dieses Beispiel benötigen wir Letzteres.

Folgende Schritte müssen für die Prüfung der Signatur eines Tokens unternommen werden:

# Schritt Erläuterung
1. Download der Signaturschlüssel https://login.microsoftonline.com/{}/discovery/v2.0/keys
2. Ermitteln der „kid“ aus dem Header „kid“: „-sxMJMLCIDWMTPvZyJ6tx-CDxw0“
3. Extraktion des Base64 codierten Signaturschlüssels aus 1. mit dem passenden Index aus 2. „x5t“: „-sxMJMLCIDWMTPvZyJ6tx-CDxw0“,
„x5c“: [„MIIDBCAeJNDyDplB…K+o5hFOOMK7y/F5r467jHez“],
4. Konvertieren des Base64 codierten Schlüssels aus 3

Erzeugen eines .NET Objektes für den Signaturschlüssel

$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]([System.Convert]::FromBase64String($SigningKey))

5. Erzeugen der Token Validation Parameter

Das Objekt wird mit den Parametern gefüllt, die mit den Werten im Token verglichen werden sollen. Darüber hinaus können Sie einzelne Tests ein-/ausschalten.

ValidateAudience : True
ValidateIssuer : True
ValidateIssuerSigningKey : True
ValidateLifetime : True
ValidateIssuerSigningKey : True
ValidAudience : api://3d89….9c21f
ValidIssuer : https://sts.windows.net//
IssuerSigningKey : System.IdentityModel.Tokens.
X509AsymmetricSecurityKey($Cert)
RequireExpirationTime : True
RequireSignedTokens : True

System.IdentityModel.Tokens.TokenValidationParameters

6. Überprüfen der Signatur

Wie oben schon erwähnt, besitzt die JWTSecurityTokenHandler Klasse eine Methode ValidateToken. Dieser Methode werden der Token zur Überprüfung, die TokenValidationParamter und eine weitere Variable übergeben.

[System.IdentityModel.Tokens.JWTSecurityTokenHandler]::new().ValidateToken($accessToken,[JSONTokenKeyValidator]::TokenValidationParameters,[ref]$validatedToken)

7. Ergebnis der Überpüfung

Die Methode aus 6. gibt einen neuen Token zurück, wenn die Überpüfung erfolgreich war oder sie wirft eine Exception

• Signature validation failed.
• Lifetime validation failed. The token is expired.
• Audience validation failed.
• Issuer validation failed.
• …

Falls Sie Fragen hierzu haben, nehmen Sie gerne Kontakt zu uns auf.

Recent Posts
Kontaktformular

Wir werden Sie so schnell wie möglich kontaktieren.

Start typing and press Enter to search