JWT (Json Web Token) Audience "aud" versus Client_Id - Was ist der Unterschied?
Ich arbeite daran, OAuth 2.0 JWT access_token auf meinem Authentifizierungsserver zu implementieren. Es ist jedoch nicht klar, worin die Unterschiede zwischen dem JWT aud -Anspruch und dem client_id HTTP-Header-Wert Sind sie gleich? Wenn nicht, können Sie den Unterschied zwischen den beiden erklären?
Mein Verdacht ist, dass aud sich auf den oder die Ressourcenserver beziehen sollte, und dass client_id Sich auf eine der Clientanwendungen beziehen sollte, die vom Authentifizierungsserver erkannt werden (dh Web-App oder iOS-App). .
In meinem aktuellen Fall ist mein Ressourcenserver auch mein Web-App-Client.
Es stellte sich heraus, dass mein Verdacht richtig war. Der Anspruch Zielgruppe aud in einer JWT bezieht sich auf die Ressourcenserver, die das Token akzeptieren sollen.
Wie this post einfach ausdrückt:
Die Zielgruppe eines Tokens ist der beabsichtigte Empfänger des Tokens.
Der Zielgruppenwert ist eine Zeichenfolge - normalerweise die Basisadresse der Ressource, auf die zugegriffen wird, z. B.
https://contoso.com.
Das client_id In OAuth) bezieht sich auf die Client-Anwendung, die Ressourcen vom Resource Server anfordert.
Die Client-App (z. B. Ihre iOS-App) fordert eine JWT von Ihrem Authentifizierungsserver an. Dabei werden client_id Und client_secret Zusammen mit den erforderlichen Benutzeranmeldeinformationen übergeben. Der Authorization Server validiert den Client mit client_id Und client_secret Und gibt eine JWT zurück.
Das JWT enthält eine aud -Anforderung, die angibt, für welche Ressourcenserver das JWT gültig ist. Wenn das audwww.myfunwebapp.com Enthält, die Client-App jedoch versucht, das JWT für www.supersecretwebapp.com Zu verwenden, wird der Zugriff verweigert, da der Resource Server erkennt, dass das JWT nicht beabsichtigt war dafür.
Der Anspruch JWT aud (Zielgruppe)
Gemäß RFC 7519 :
Der Anspruch "aud" (Audience) identifiziert die Empfänger, für die das JWT bestimmt ist. Jeder Auftraggeber, der die JWT verarbeiten soll, MUSS sich mit einem Wert im Anspruch des Publikums identifizieren. Wenn sich der Auftraggeber, der die Forderung bearbeitet, bei Vorliegen dieser Forderung nicht mit einem Wert in der Forderung "aud" identifiziert, MUSS die GAG abgelehnt werden. Im Allgemeinen ist der Wert "aud" ein Array von Zeichenfolgen, bei denen zwischen Groß- und Kleinschreibung unterschieden wird. Jede Zeichenfolge enthält einen StringOrURI-Wert. In dem speziellen Fall, dass die JWT eine Zielgruppe hat, kann der Wert "aud" eine einzelne Zeichenfolge sein, bei der die Groß- und Kleinschreibung beachtet wird und die einen StringOrURI-Wert enthält. Die Interpretation der Zielgruppenwerte ist im Allgemeinen anwendungsspezifisch. Die Verwendung dieses Anspruchs ist OPTIONAL.
Der in der Spezifikation definierte Anspruch "Zielgruppe" (aud) ist generisch und anwendungsspezifisch. Die beabsichtigte Verwendung besteht darin, die beabsichtigten Empfänger des Tokens zu identifizieren. Was ein Empfänger bedeutet, ist anwendungsspezifisch. Ein Zielgruppenwert ist entweder eine Liste von Zeichenfolgen oder kann eine einzelne Zeichenfolge sein, wenn nur eine aud -Anforderung vorhanden ist. Der Ersteller des Tokens erzwingt nicht, dass aud korrekt validiert wird. Es liegt in der Verantwortung des Empfängers, zu bestimmen, ob das Token verwendet werden soll.
Unabhängig vom Wert MUSS ein Empfänger, der das JWT validiert und bestätigen möchte, dass das Token für seine Zwecke verwendet werden soll, bestimmen, welcher Wert in aud sich selbst identifiziert, und das Token sollte nur validieren wenn die deklarierte ID des Empfängers im Anspruch aud vorhanden ist. Es spielt keine Rolle, ob dies eine URL oder eine andere anwendungsspezifische Zeichenfolge ist. Wenn sich mein System beispielsweise in aud mit der Zeichenfolge api3.app.com Identifiziert, sollte es das JWT nur akzeptieren, wenn der Anspruch audapi3.app.com Enthält Liste der Zielgruppenwerte.
Natürlich können Empfänger aud ignorieren. Dies ist nur dann sinnvoll, wenn ein Empfänger eine positive Bestätigung möchte, dass das Token speziell für ihn erstellt wurde.
Meine auf der Spezifikation basierende Interpretation ist, dass die Behauptung aud nützlich ist, um speziell erstellte JWTs zu erstellen, die nur für bestimmte Zwecke gültig sind. Für ein System kann dies bedeuten, dass Sie möchten, dass ein Token für einige Funktionen gültig ist, für andere jedoch nicht. Sie können Token ausgeben, die nur für eine bestimmte "Zielgruppe" bestimmt sind und dennoch dieselben Schlüssel und denselben Validierungsalgorithmus verwenden.
Da im typischen Fall eine JWT von einem vertrauenswürdigen Dienst generiert und von anderen vertrauenswürdigen Systemen (Systemen, die keine ungültigen Token verwenden möchten) verwendet wird, müssen diese Systeme lediglich die Werte koordinieren, die sie verwenden werden.
Natürlich ist aud völlig optional und kann ignoriert werden, wenn Ihr Anwendungsfall dies nicht rechtfertigt. Wenn Sie nicht möchten, dass Token nur von bestimmten Zielgruppen verwendet werden, oder keines Ihrer Systeme das Token aud tatsächlich validiert, ist es unbrauchbar.
Beispiel: Zugriffstoken vs. Aktualisierungstoken
Ein ausgefallenes (und dennoch einfaches) Beispiel, an das ich denken kann, ist, dass wir JWTs für Zugriffs- und Aktualisierungstoken verwenden möchten, ohne separate Verschlüsselungsschlüssel und Algorithmen implementieren zu müssen, aber einfach sicherstellen möchten, dass Zugriffstoken nicht als Aktualisierungstoken oder umgekehrt validiert werden -versa.
Mit aud können wir einen Anspruch von refresh für Aktualisierungstoken und einen Anspruch von access für Zugriffstoken beim Erstellen dieser Token angeben. Wenn eine Anforderung zum Abrufen eines neuen Zugriffstokens von einem Aktualisierungstoken gestellt wird, müssen wir überprüfen, ob es sich bei dem Aktualisierungstoken um ein echtes Aktualisierungstoken handelt. Die aud -Validierung wie oben beschrieben gibt Aufschluss darüber, ob das Token tatsächlich ein gültiges Aktualisierungstoken war, indem in refresh nach einem Anspruch von aud gesucht wird.
OAuth Client ID vs. JWT aud Claim
Die OAuth Client-ID steht in keiner direkten Beziehung zu den Ansprüchen von JWT aud. Aus der Sicht von OAuth sind die Token undurchsichtige Objekte.
Die Anwendung, die diese Token akzeptiert, ist dafür verantwortlich, die Bedeutung dieser Token zu analysieren und zu validieren. Ich sehe nicht viel Wert darin, die OAuth Client-ID in einem JWT aud -Anspruch anzugeben.