8. Erweiterbarkeit (Extensibility)

8.1. Definition von Zugangstoken-Typen (Defining Access Token Types)

Zugangstoken-Typen (Access Token Types) können auf eine von zwei Arten definiert werden: durch Registrierung im Zugangstoken-Typen-Register (gemäß den Verfahren in Abschnitt 11.1) oder durch Verwendung eines eindeutigen absoluten URI als Name.

Typen, die einen URI-Namen verwenden, sollten (SHOULD) auf herstellerspezifische Implementierungen beschränkt sein, die nicht allgemein anwendbar sind und spezifisch für die Implementierungsdetails des Ressourcenservers (Resource Server) sind, auf dem sie verwendet werden.

Alle anderen Typen müssen (MUST) registriert werden. Typnamen müssen (MUST) dem type-name ABNF entsprechen. Wenn die Typdefinition ein neues HTTP-Authentifizierungsschema enthält, sollte (SHOULD) der Typname mit dem HTTP-Authentifizierungsschemanamen identisch sein (wie in [RFC2617] definiert). Der Token-Typ „example" ist für die Verwendung in Beispielen reserviert.

type-name  = 1*name-char
name-char  = "-" / "." / "_" / DIGIT / ALPHA

8.2. Definition neuer Endpunkt-Parameter (Defining New Endpoint Parameters)

Neue Anforderungs- oder Antwortparameter zur Verwendung mit dem Autorisierungs-Endpunkt (Authorization Endpoint) oder dem Token-Endpunkt (Token Endpoint) werden im OAuth-Parameter-Register gemäß dem Verfahren in Abschnitt 11.2 definiert und registriert.

Parameternamen müssen (MUST) dem param-name ABNF entsprechen, und die Syntax der Parameterwerte muss (MUST) gut definiert sein (z. B. unter Verwendung von ABNF oder einem Verweis auf die Syntax eines vorhandenen Parameters).

param-name  = 1*name-char
name-char   = "-" / "." / "_" / DIGIT / ALPHA

Nicht registrierte herstellerspezifische Parametererweiterungen, die nicht allgemein anwendbar sind und spezifisch für die Implementierungsdetails des Autorisierungsservers (Authorization Server) sind, auf dem sie verwendet werden, sollten (SHOULD) ein herstellerspezifisches Präfix verwenden, das wahrscheinlich nicht mit anderen registrierten Werten in Konflikt steht (z. B. mit „companyname_" beginnen).

8.3. Definition neuer Autorisierungstypen (Defining New Authorization Grant Types)

Neue Autorisierungstypen (Authorization Grant Types) können definiert werden, indem ihnen ein eindeutiger absoluter URI zur Verwendung mit dem Parameter „grant_type" zugewiesen wird. Wenn der Erweiterungsautorisierungstyp zusätzliche Token-Endpunkt-Parameter erfordert, müssen (MUST) diese im OAuth-Parameter-Register registriert werden, wie in Abschnitt 11.2 beschrieben.

8.4. Definition neuer Autorisierungs-Endpunkt-Antworttypen (Defining New Authorization Endpoint Response Types)

Neue Antworttypen zur Verwendung mit dem Autorisierungs-Endpunkt werden im Register der Autorisierungs-Endpunkt-Antworttypen gemäß dem Verfahren in Abschnitt 11.3 definiert und registriert. Antworttypnamen müssen (MUST) dem response-type ABNF entsprechen.

response-type  = response-name *( SP response-name )
response-name  = 1*response-char
response-char  = "_" / DIGIT / ALPHA

Wenn ein Antworttyp ein oder mehrere Leerzeichen (%x20) enthält, wird er als durch Leerzeichen getrennte Liste von Werten verglichen, bei der die Reihenfolge der Werte keine Rolle spielt. Es kann nur eine Reihenfolge von Werten registriert werden, die alle anderen Anordnungen desselben Satzes von Werten abdeckt.

Beispielsweise ist der Antworttyp „token code" durch diese Spezifikation nicht definiert. Eine Erweiterung kann jedoch den Antworttyp „token code" definieren und registrieren. Nach der Registrierung kann dieselbe Kombination nicht als „code token" registriert werden, aber beide Werte können verwendet werden, um denselben Antworttyp zu bezeichnen.

8.5. Definition zusätzlicher Fehlercodes (Defining Additional Error Codes)

In Fällen, in denen Protokollerweiterungen (d. h. Zugangstoken-Typen, Erweiterungsparameter oder Erweiterungsautorisierungstypen) zusätzliche Fehlercodes erfordern, die mit der Autorisierungscode-Fehlerantwort (Abschnitt 4.1.2.1), der impliziten Autorisierungs-Fehlerantwort (Abschnitt 4.2.2.1), der Token-Fehlerantwort (Abschnitt 5.2) oder der Ressourcenzugriffs-Fehlerantwort (Abschnitt 7.2) verwendet werden, können (MAY) solche Fehlercodes definiert werden.

Erweiterungs-Fehlercodes müssen (MUST) registriert werden (gemäß den Verfahren in Abschnitt 11.4), wenn die Erweiterung, mit der sie verwendet werden, ein registrierter Zugangstoken-Typ, ein registrierter Endpunkt-Parameter oder ein Erweiterungsautorisierungstyp ist. Fehlercodes, die mit nicht registrierten Erweiterungen verwendet werden, können (MAY) registriert werden.

Fehlercodes müssen (MUST) dem error ABNF entsprechen und sollten (SHOULD) nach Möglichkeit mit einem Identifikationsnamen versehen werden. Beispielsweise sollte (SHOULD) ein Fehler, der einen ungültigen Wert für den Erweiterungsparameter „example" identifiziert, „example_invalid" genannt werden.

error      = 1*error-char
error-char = %x20-21 / %x23-5B / %x5D-7E

---