Passa al contenuto principale

8. Estensibilità (Extensibility)

8.1. Definizione dei tipi di token di accesso (Defining Access Token Types)​

I tipi di token di accesso (Access Token Types) possono essere definiti in due modi: registrati nel registro dei tipi di token di accesso (seguendo le procedure nella sezione 11.1), o utilizzando un URI assoluto univoco come nome.

I tipi che utilizzano un nome URI dovrebbero (SHOULD) essere limitati alle implementazioni specifiche del fornitore che non sono comunemente applicabili e sono specifiche ai dettagli di implementazione del server delle risorse (Resource Server) dove vengono utilizzati.

Tutti gli altri tipi devono (MUST) essere registrati. I nomi dei tipi devono (MUST) essere conformi all'ABNF type-name. Se la definizione del tipo include un nuovo schema di autenticazione HTTP, il nome del tipo dovrebbe (SHOULD) essere identico al nome dello schema di autenticazione HTTP (come definito da [RFC2617]). Il tipo di token « example » è riservato per l'uso negli esempi.

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

8.2. Definizione di nuovi parametri dell'endpoint (Defining New Endpoint Parameters)​

I nuovi parametri di richiesta o risposta da utilizzare con l'endpoint di autorizzazione (Authorization Endpoint) o l'endpoint del token (Token Endpoint) sono definiti e registrati nel registro dei parametri OAuth seguendo la procedura nella sezione 11.2.

I nomi dei parametri devono (MUST) essere conformi all'ABNF param-name, e la sintassi dei valori dei parametri deve (MUST) essere ben definita (ad esempio, utilizzando ABNF o un riferimento alla sintassi di un parametro esistente).

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

Le estensioni di parametri specifiche del fornitore non registrate che non sono comunemente applicabili e che sono specifiche ai dettagli di implementazione del server di autorizzazione (Authorization Server) dove vengono utilizzate dovrebbero (SHOULD) utilizzare un prefisso specifico del fornitore che non è probabile che entri in conflitto con altri valori registrati (ad esempio, iniziare con « companyname_ »).

8.3. Definizione di nuovi tipi di autorizzazione (Defining New Authorization Grant Types)​

I nuovi tipi di autorizzazione (Authorization Grant Types) possono essere definiti assegnando loro un URI assoluto univoco da utilizzare con il parametro « grant_type ». Se il tipo di autorizzazione di estensione richiede parametri aggiuntivi dell'endpoint del token, questi devono (MUST) essere registrati nel registro dei parametri OAuth come descritto nella sezione 11.2.

8.4. Definizione di nuovi tipi di risposta dell'endpoint di autorizzazione (Defining New Authorization Endpoint Response Types)​

I nuovi tipi di risposta da utilizzare con l'endpoint di autorizzazione sono definiti e registrati nel registro dei tipi di risposta dell'endpoint di autorizzazione seguendo la procedura nella sezione 11.3. I nomi dei tipi di risposta devono (MUST) essere conformi all'ABNF response-type.

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

Se un tipo di risposta contiene uno o più caratteri di spazio (%x20), viene confrontato come un elenco di valori delimitato da spazi in cui l'ordine dei valori non ha importanza. Può essere registrato solo un ordine di valori, che copre tutte le altre disposizioni dello stesso insieme di valori.

Ad esempio, il tipo di risposta « token code » è lasciato non definito da questa specifica. Tuttavia, un'estensione può definire e registrare il tipo di risposta « token code ». Una volta registrato, la stessa combinazione non può essere registrata come « code token », ma entrambi i valori possono essere utilizzati per denotare lo stesso tipo di risposta.

8.5. Definizione di codici di errore aggiuntivi (Defining Additional Error Codes)​

Nei casi in cui le estensioni del protocollo (cioè tipi di token di accesso, parametri di estensione o tipi di autorizzazione di estensione) richiedono codici di errore aggiuntivi da utilizzare con la risposta di errore di autorizzazione tramite codice (sezione 4.1.2.1), la risposta di errore di autorizzazione implicita (sezione 4.2.2.1), la risposta di errore del token (sezione 5.2) o la risposta di errore di accesso alle risorse (sezione 7.2), tali codici di errore possono (MAY) essere definiti.

I codici di errore di estensione devono (MUST) essere registrati (seguendo le procedure nella sezione 11.4) se l'estensione con cui vengono utilizzati è un tipo di token di accesso registrato, un parametro di endpoint registrato o un tipo di autorizzazione di estensione. I codici di errore utilizzati con estensioni non registrate possono (MAY) essere registrati.

I codici di errore devono (MUST) essere conformi all'ABNF error e dovrebbero (SHOULD) essere prefissati da un nome identificativo quando possibile. Ad esempio, un errore che identifica un valore non valido impostato sul parametro di estensione « example » dovrebbe (SHOULD) essere chiamato « example_invalid ».

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