Was passiert während eines AcquireTokenAsync-Aufrufs mit dem Client-Zertifikat?

Question

In Azure AD, wenn wir einen Anruf wie AuthenticationContext.AcquireTokenAsync(resource, new ClientAssertionCertificate(_clientId, _cert)) machen, ist es nicht klar, was genau passiert.

Welcher Teil des Zertifikats wird ggf. ausgetauscht?

Gibt es eine Herausforderung/Antwort?

Ist der private Schlüssel auf dem Client als Teil davon erforderlich?

Answer 1

Es gibt zwei Möglichkeiten, wie Sie die Antwort auf Ihre Fragen finden können. Eine wäre, die Microsoft Active Directory-Authentifizierungsbibliothek (ADAL) für .NET source code on GitHub zu betrachten, da dies Open-Source ist. Der andere (den wir hier machen) ist, die Netzwerkanforderung zu betrachten, die AcquireTokenAsync(String, ClientAssertion) erzeugt, und von dort rückwärts zu arbeiten.

Mit Fiddler (oder einem anderen Traffic-Analyzer) können wir so etwas wie die folgenden (formatiert für Lesbarkeit) siehe:

POST https://login.microsoftonline.com/{tenant-id}/oauth2/token HTTP/1.1 
Content-Type: application/x-www-form-urlencoded 

grant_type=client_credentials 
&resource=https%3A%2F%2Fgraph.windows.net 
&client_id={app-id} 
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer 
&client_assertion=eyJhbGciOiJSUzI1N...VE8wHSf-HZvGQ 

es Breaking down:

• grant_type=client_credentials sagt uns, dies ist ein Token-Anfrage mit dem OAuth 2.0 Client Credentials Grant Flow.
• resource=https%3A%2F%2Fgraph.windows.net gibt den URI der Ressource an, für die der Client ein Zugriffs-Token anfordert. In diesem Fall handelt es sich um die Azure AD Graph-API.
• client_id={app-id} ist die client identifier. In Azure AD ist dies die App-ID der Anwendung, die registriert wurde.
• Die Anwesenheit von client_assertion_type und client_assertion sind indikativ, dass der Client eine assertion zum Authentifizieren verwendet:
  • client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer sagt, dass Client Behauptung JSON Web Token (JWT) ein signiertes verwendet wird.
  • client_assertion=eyJhbGciOiJSUzI1N...VE8wHSf-HZvGQ ist der oben genannte signierte JWT-Token. Der Autorisierungsserver (z. B. Azure AD) überprüft den Inhalt und überprüft, ob das Token tatsächlich von dem für den betreffenden Client autorisierten Zertifikat signiert wurde.

Also, was ADAL tut, ist:

1. Konstruieren Sie einen Token mit einer Reihe von Behauptungen über den Client (App)
2. privaten Schlüssel Ihres Zertifikats Verwenden Sie eine kryptografische Signatur zu erzeugen, von diesen Ansprüchen
3. Bündeln Sie das bis in eine signierte JWT
4. Machen Sie eine entsprechend gebildete Token-Anfrage an die Behörde

Während AcquireTokenAsync wird nur der Fingerabdruck des Zertifikats bereitgestellt (es ist im JWT-Header enthalten, damit der Autorisierungsserver den entsprechenden öffentlichen Schlüssel nachschlagen kann). Die Unterschrift des JWT beweist, dass der Kunde im Besitz des privaten Schlüssels ist. Jedoch kann vorAcquireTokenAsync(String, ClientAssertion) erfolgreich verwendet werden, der Kundenbesitzer (d. H.Sie müssen Azure AD mit dem öffentlichen Schlüssel des Zertifikats versehen haben.

Hier findet keine Challenge/Response statt. Das Token wird in einer einzigen Anfrage erhalten, die vom Client initiiert wird.

für viel mehr Detail, können Sie die Standards überprüfen, dass dies alles Arbeitsgeräte:

• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 7521: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 7519: JSON Web Token (JWT)

(Beachten Sie, dass ADAL hat ein Cache, alles was ich oben beschrieben habe findet statt nly, wenn ADAL kein gültiges Zugriffstoken im Token-Cache findet. Sie können AuthenticationContext.TokenCache.Clear() verwenden, um den Cache für Experimente zu löschen.)