1. Einführung
Ein Sicherheitstoken ist eine Sammlung von Informationen, die den Austausch von Identitäts- und Sicherheitsinformationen in heterogenen Umgebungen oder über Sicherheitsdomänen hinweg erleichtert. Beispiele für Sicherheitstokens sind JSON Web Tokens (JWTs) [JWT] und Security Assertion Markup Language (SAML) 2.0 Assertions [OASIS.saml-core-2.0-os]. Sicherheitstokens werden normalerweise signiert, um Integrität zu erreichen, und manchmal auch verschlüsselt, um Vertraulichkeit zu erreichen. Sicherheitstokens werden manchmal auch als Assertions beschrieben, wie zum Beispiel in [RFC7521].
Ein Security Token Service (STS) ist ein Dienst, der in der Lage ist, ihm bereitgestellte Sicherheitstokens zu validieren und als Antwort neue Sicherheitstokens auszustellen, was es Clients ermöglicht, geeignete Zugriffsnachweise für Ressourcen in heterogenen Umgebungen oder über Sicherheitsdomänen hinweg zu erhalten. Web Service Clients haben WS-Trust [WS-Trust] als Protokoll verwendet, um mit einem STS für den Token-Austausch zu interagieren. Während WS-Trust XML und SOAP verwendet, geht der Trend in der modernen Webentwicklung hin zu RESTful (Representational State Transfer) Mustern und JSON. Das OAuth 2.0-Autorisierungsframework [RFC6749] und OAuth 2.0 Bearer Tokens [RFC6750] haben sich als beliebte Standards für die Autorisierung des Zugriffs von Drittanbieteranwendungen auf HTTP- und RESTful-Ressourcen etabliert. Die konventionelle OAuth 2.0-Interaktion beinhaltet den Austausch einer Darstellung der Autorisierung des Ressourceninhabers gegen ein Zugriffstoken, was sich in der Praxis als äußerst nützliches Muster erwiesen hat. Allerdings sind seine Ein- und Ausgaben in ihrer jetzigen Form etwas zu eingeschränkt, um ein Rahmenwerk für den Austausch von Sicherheitstokens vollständig aufzunehmen.
Diese Spezifikation definiert ein Protokoll, das OAuth 2.0 erweitert und es Clients ermöglicht, Sicherheitstokens von Autorisierungssenvern anzufordern und zu erhalten, die in der Rolle eines STS handeln. Ähnlich wie OAuth 2.0 konzentriert sich diese Spezifikation auf die Einfachheit für Client-Entwickler und erfordert nur einen HTTP-Client und einen JSON-Parser, die in modernen Entwicklungsumgebungen nahezu universell verfügbar sind. Das in dieser Spezifikation definierte STS-Protokoll ist selbst nicht RESTful (ein STS eignet sich nicht besonders gut für einen REST-Ansatz), nutzt jedoch Kommunikationsmuster und Datenformate, die Entwicklern vertraut sein sollten, die an die Arbeit mit RESTful-Systemen gewöhnt sind.
Ein neuer Grant-Typ für eine Token-Austauschanforderung und die zugehörigen spezifischen Parameter für eine solche Anforderung an den Token-Endpunkt werden durch diese Spezifikation definiert. Eine Token-Austauschantwort ist eine normale OAuth 2.0-Antwort vom Token-Endpunkt mit einigen zusätzlichen, hier definierten Parametern, um dem Client Informationen bereitzustellen.
Die Entität, die die Anforderung zum Austausch von Tokens stellt, wird im Kontext der Token-Austauschinteraktion als Client betrachtet. Dies beschränkt die Verwendung dieses Profils jedoch nicht auf traditionelle OAuth-Clients. Ein OAuth-Ressourcenserver könnte beispielsweise während des Token-Austauschs die Rolle des Clients übernehmen, um ein Zugriffstoken, das er in einer Anforderung an eine geschützte Ressource erhalten hat, gegen ein neues Token einzutauschen, das geeignet ist, in einen Aufruf an einen Backend-Dienst aufgenommen zu werden. Das neue Token könnte ein Zugriffstoken sein, das für den nachgelagerten Dienst enger gefasst ist, oder es könnte eine völlig andere Art von Token sein.
Der Umfang dieser Spezifikation beschränkt sich auf die Definition eines grundlegenden Anforderungs- und Antwortprotokolls für einen STS-artigen Token-Austausch unter Verwendung von OAuth 2.0. Obwohl einige neue JWT-Claims definiert werden, die es ermöglichen, Delegierungssemantiken auszudrücken, liegen die spezifische Syntax, Semantik und Sicherheitsmerkmale der Tokens selbst (sowohl derjenigen, die dem Autorisierungsserver präsentiert werden, als auch derjenigen, die vom Client erhalten werden) explizit außerhalb des Geltungsbereichs, und es werden keine Anforderungen an das Vertrauensmodell gestellt, in dem eine Implementierung bereitgestellt werden könnte. Zusätzliche Profile können detailliertere Anforderungen an die spezifische Art der beteiligten Parteien und des Vertrauens stellen, wie z. B. ob Signierung und/oder Verschlüsselung von Tokens erforderlich ist oder ob Tokens im Proof-of-Possession-Stil erforderlich oder ausgestellt werden. Solche Details sind jedoch oft Richtlinienentscheidungen, die im Hinblick auf die spezifischen Bedürfnisse einzelner Bereitstellungen getroffen werden und entsprechend konfiguriert oder implementiert werden.
Die erhaltenen Sicherheitstokens können in einer Reihe von Kontexten verwendet werden, deren Einzelheiten ebenfalls über den Umfang dieser Spezifikation hinausgehen.
1.1. Delegierungs- vs. Identitätswechsel-Semantik
Ein häufiger Anwendungsfall für einen STS (wie im vorherigen Abschnitt angedeutet) besteht darin, es einem Ressourcenserver A zu ermöglichen, im Namen des anfordernden Benutzers B Aufrufe an einen Backend-Dienst C zu tätigen. Abhängig von den lokalen Standortrichtlinien und der Autorisierungsinfrastruktur kann es wünschenswert sein, dass A seine eigenen Anmeldeinformationen verwendet, um auf C zuzugreifen, zusammen mit einer Anmerkung irgendeiner Form, dass A im Namen von B handelt ("Delegierung"), oder dass A ein begrenzter Zugriffsnachweis für C gewährt wird, der jedoch weiterhin B als die autorisierte Entität identifiziert ("Identitätswechsel"). Delegierung und Identitätswechsel können auch in anderen Szenarien mit mehreren Teilnehmern nützliche Konzepte sein.
Wenn Prinzipal A Prinzipal B imitiert (Identitätswechsel), erhält A alle Rechte, die B innerhalb eines definierten Rechtekontexts hat, und ist in diesem Kontext nicht von B zu unterscheiden. Wenn also Prinzipal A Prinzipal B imitiert, dann haben es alle Entitäten, die ein solches Token erhalten, tatsächlich mit B zu tun. Es ist wahr, dass einige Mitglieder des Identitätssystems Kenntnis davon haben könnten, dass ein Identitätswechsel stattfindet, aber das ist keine Anforderung. Für alle Absichten und Zwecke, wenn A B imitiert, ist A im Kontext der durch das Token autorisierten Rechte B. Die Fähigkeit von A, B zu imitieren, könnte in Umfang oder Zeit begrenzt sein, oder sogar mit einer Einmalnutzungsbeschränkung versehen sein, sei es über den Inhalt des Tokens oder einen Out-of-Band-Mechanismus.
Delegierungssemantiken unterscheiden sich von Identitätswechselsemantiken, obwohl die beiden eng miteinander verwandt sind. Bei Delegierungssemantiken hat Prinzipal A immer noch seine eigene, von B getrennte Identität, und es wird explizit verstanden, dass, während B einige seiner Rechte an A delegiert haben mag, alle ergriffenen Maßnahmen von A als Vertreter von B ergriffen werden. In gewissem Sinne ist A ein Agent für B.
Delegierung und Identitätswechsel schließen nicht alle Situationen ein. Wenn ein Prinzipal direkt in seinem eigenen Namen handelt, sind beispielsweise weder Delegierung noch Identitätswechsel im Spiel. Sie sind jedoch die gebräuchlicheren Semantiken, die für den Token-Austausch gelten, und werden daher in dieser Spezifikation direkter behandelt.
Delegierungssemantiken werden typischerweise in einem Token ausgedrückt, indem Informationen sowohl über das primäre Subjekt des Tokens als auch über den Akteur aufgenommen werden, an den dieses Subjekt einige seiner Rechte delegiert hat. Ein solches Token wird manchmal als Verbundtoken bezeichnet, da es aus Informationen über mehrere Subjekte besteht. Typischerweise repräsentiert in der Anforderung das "subject_token" die Identität der Partei, in deren Namen das Token angefordert wird, während das "actor_token" die Identität der Partei repräsentiert, an die die Zugriffsrechte des ausgestellten Tokens delegiert werden. Ein vom Autorisierungsserver ausgestelltes Verbundtoken enthält Informationen über beide Parteien. Ob und wann ein Verbundtoken ausgestellt wird, liegt im Ermessen des Autorisierungsservers und der geltenden Richtlinien und Konfiguration.
Die Einzelheiten der Darstellung eines Verbundtokens und sogar ob ein solches Token ausgestellt wird oder nicht, hängen von den Details der Implementierung und der Art des Tokens ab. Die Darstellungen von Verbundtokens, die keine JWTs sind, liegen außerhalb des Geltungsbereichs dieser Spezifikation. Der Anforderungsparameter "actor_token" bietet jedoch eine Möglichkeit, Informationen über den gewünschten Akteur bereitzustellen, und der JWT-"act"-Claim kann eine Darstellung einer Delegierungskette liefern.
1.2. Anforderungsnotation und Konventionen
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn, und nur wenn, sie in Großbuchstaben erscheinen, wie hier gezeigt.
1.3. Terminologie
Diese Spezifikation verwendet die Begriffe "access token type", "authorization server", "client", "client identifier", "resource server", "token endpoint", "token request" und "token response", definiert durch OAuth 2.0 [RFC6749], und die Begriffe "Base64url Encoding", "Claim" und "JWT Claims Set", definiert durch JSON Web Token (JWT) [JWT].