Anhang A. Anwendungsfälle
Dieser Anhang beschreibt verschiedene Möglichkeiten, wie diese Spezifikation genutzt werden kann, einschließlich der Beschreibung einiger der Entscheidungen, die möglicherweise getroffen werden müssen. Einige der Entscheidungen sind unabhängig und können kombiniert werden, während einige der Entscheidungen miteinander verbunden sind.
A.1. Offene versus geschützte dynamische Client-Registrierung
A.1.1. Offene dynamische Client-Registrierung
Autorisierungsserver, die offene Registrierung unterstützen, erlauben Registrierungen ohne initiales Zugriffstoken. Dies ermöglicht es allen Client-Software, sich beim Autorisierungsserver zu registrieren.
A.1.2. Geschützte dynamische Client-Registrierung
Autorisierungsserver, die geschützte Registrierung unterstützen, verlangen, dass ein initiales Zugriffstoken verwendet wird, wenn Registrierungsanfragen gestellt werden. Während die Methode, durch die ein Client oder Entwickler dieses initiale Zugriffstoken erhält, und die Methode, durch die der Autorisierungsserver dieses initiale Zugriffstoken validiert, außerhalb des Geltungsbereichs dieser Spezifikation liegen, ist ein gängiger Ansatz, dass der Entwickler ein manuelles Vorabregistrierungsportal auf dem Autorisierungsserver verwendet, das dem Entwickler ein initiales Zugriffstoken ausstellt.
A.2. Registrierung ohne oder mit Software Statements
A.2.1. Registrierung ohne Software Statement
Wenn ein Software Statement nicht in der Registrierungsanfrage verwendet wird, muss der Autorisierungsserver bereit sein, Client-Metadatenwerte zu verwenden, ohne dass sie von einer Behörde digital signiert oder mit einem MAC versehen (und dadurch bestätigt) wurden. (Beachten Sie, dass diese Wahl unabhängig von der Wahl Offen versus Geschützt ist und dass ein initiales Zugriffstoken eine andere mögliche Form der Bestätigung ist.)
A.2.2. Registrierung mit einem Software Statement
Ein Software Statement kann in einer Registrierungsanfrage verwendet werden, um eine Bestätigung durch eine Behörde für eine Reihe von Client-Metadatenwerten bereitzustellen. Dies kann nützlich sein, wenn der Autorisierungsserver die Registrierung auf Client-Software beschränken möchte, die von einer Reihe von Behörden bestätigt wurde, oder wenn er wissen möchte, dass mehrere Registrierungsanfragen auf dasselbe Stück Client-Software verweisen.
A.3. Registrierung durch den Client oder Entwickler
A.3.1. Registrierung durch den Client
In einigen Anwendungsfällen registriert sich die Client-Software selbst dynamisch beim Autorisierungsserver, um einen Client-Identifikator und andere Informationen zu erhalten, die für die Interaktion mit dem Autorisierungsserver erforderlich sind. In diesem Fall wird kein Client-Identifikator für den Autorisierungsserver mit der Client-Software verpackt.
A.3.2. Registrierung durch den Entwickler
In einigen Fällen wird der Entwickler (oder die vom Entwickler verwendete Entwicklungssoftware) die Client-Software beim Autorisierungsserver oder bei einer Reihe von Autorisierungsservern vorab registrieren. In diesem Fall können die Client-Identifikatorwerte für die Autorisierungsserver mit der Client-Software verpackt werden.
A.4. Client-ID pro Client-Instanz oder pro Client-Software
A.4.1. Client-ID pro Client-Software-Instanz
In einigen Fällen wird jede bereitgestellte Instanz einer Client-Software sich dynamisch registrieren und unterschiedliche Client-Identifikatorwerte erhalten. Dies kann vorteilhaft sein, wenn beispielsweise der Code-Flow verwendet wird, da es auch jeder Client-Instanz ermöglicht, ihr eigenes Client-Secret zu haben. Dies kann für native Clients nützlich sein, die die Geheimhaltung eines mit der Software verpackten Client-Secret-Wertes nicht aufrechterhalten können, aber möglicherweise in der Lage sind, die Geheimhaltung eines instanzspezifischen Client-Secrets aufrechtzuerhalten.
A.4.2. Von allen Instanzen der Client-Software gemeinsam genutzte Client-ID
In einigen Fällen wird jede bereitgestellte Instanz einer Client-Software einen gemeinsamen Client-Identifikatorwert teilen. Dies ist beispielsweise häufig bei In-Browser-Clients der Fall, die den impliziten Flow verwenden, wenn kein Client-Secret beteiligt ist. Bestimmte Autorisierungsserver könnten beispielsweise wählen, ein Mapping zwischen Software-Statement-Werten und Client-Identifikatorwerten zu pflegen und denselben Client-Identifikatorwert für alle Registrierungsanfragen für ein bestimmtes Stück Software zurückzugeben. Die Umstände, unter denen ein Autorisierungsserver dies tun würde, und die spezifischen Software-Statement-Eigenschaften, die in diesem Fall erforderlich sind, liegen außerhalb des Geltungsbereichs dieser Spezifikation.
A.5. Zustandsbehaftete oder zustandslose Registrierung
A.5.1. Zustandsbehaftete Client-Registrierung
In einigen Fällen werden Autorisierungsserver Zustand über registrierte Clients pflegen, typischerweise diesen Zustand unter Verwendung des Client-Identifikatorwertes indizieren. Dieser Zustand würde typischerweise die Client-Metadatenwerte umfassen, die mit der Client-Registrierung verbunden sind, und möglicherweise anderen Zustand, der für die Implementierung des Autorisierungsservers spezifisch ist. Wenn zustandsbehaftete Registrierung verwendet wird, können Operationen zum Abrufen und/oder Aktualisieren dieses Zustands unterstützt werden. Ein möglicher Satz von Operationen auf zustandsbehafteten Registrierungen wird in [RFC7592] beschrieben.
A.5.2. Zustandslose Client-Registrierung
In einigen Fällen werden Autorisierungsserver so implementiert, dass sie keinen lokalen Zustand über registrierte Clients pflegen müssen. Eine Möglichkeit, dies zu tun, besteht darin, den gesamten Registrierungszustand im zurückgegebenen Client-Identifikatorwert zu kodieren und möglicherweise den Zustand zum Autorisierungsserver zu verschlüsseln, um die Vertraulichkeit und Integrität des Zustands aufrechtzuerhalten.