7. Accesso alle risorse protette (Accessing Protected Resources)

Il client (Client) accede alle risorse protette presentando il token di accesso (Access Token) al server delle risorse (Resource Server). Il server delle risorse deve (MUST) convalidare il token di accesso e assicurarsi che non sia scaduto e che il suo ambito (Scope) copra la risorsa richiesta. I metodi utilizzati dal server delle risorse per convalidare il token di accesso (così come qualsiasi risposta di errore) vanno oltre l'ambito di questa specifica, ma generalmente coinvolgono un'interazione o un coordinamento tra il server delle risorse e il server di autorizzazione (Authorization Server).

Il metodo con cui il client utilizza il token di accesso per autenticarsi presso il server delle risorse dipende dal tipo di token di accesso emesso dal server di autorizzazione. Tipicamente, ciò comporta l'uso del campo di intestazione della richiesta HTTP « Authorization » [RFC2617] con uno schema di autenticazione definito dalla specifica del tipo di token di accesso utilizzato, come [RFC6750].

7.1. Tipi di token di accesso (Access Token Types)

Il tipo di token di accesso (Access Token Type) fornisce al client le informazioni necessarie per utilizzare con successo il token di accesso per effettuare una richiesta di risorsa protetta (insieme agli attributi specifici del tipo). Il client non deve (MUST NOT) utilizzare un token di accesso se non comprende il tipo di token.

Ad esempio, il tipo di token « bearer » definito in [RFC6750] viene utilizzato semplicemente includendo la stringa del token di accesso nella richiesta:

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM

Mentre il tipo di token « mac » definito in [OAuth-HTTP-MAC] viene utilizzato emettendo una chiave di codice di autenticazione dei messaggi (Message Authentication Code, MAC) insieme al token di accesso che viene utilizzato per firmare determinati componenti delle richieste HTTP:

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
                   nonce="274312:dj83hs9s",
                   mac="kDZvddkndxvhGRXZhvuDjEWhGeE="

Gli esempi sopra sono forniti solo a scopo illustrativo. Si consiglia agli sviluppatori di consultare le specifiche [RFC6750] e [OAuth-HTTP-MAC] prima dell'uso.

Ogni definizione del tipo di token di accesso specifica gli attributi aggiuntivi (se presenti) inviati al client insieme al parametro di risposta « access_token ». Definisce anche il metodo di autenticazione HTTP utilizzato per includere il token di accesso quando si effettua una richiesta di risorsa protetta.

7.2. Risposta di errore (Error Response)

Se una richiesta di accesso alle risorse fallisce, il server delle risorse dovrebbe (SHOULD) informare il client dell'errore. Sebbene i dettagli di tali risposte di errore vadano oltre l'ambito di questa specifica, questo documento stabilisce un registro comune nella sezione 11.4 per i valori di errore da condividere tra gli schemi di autenticazione dei token OAuth.

I nuovi schemi di autenticazione progettati principalmente per l'autenticazione dei token OAuth dovrebbero (SHOULD) definire un meccanismo per fornire un codice di stato di errore al client, in cui i valori di errore consentiti sono registrati nel registro degli errori stabilito da questa specifica.

Tali schemi possono (MAY) limitare l'insieme dei codici di errore validi a un sottoinsieme dei valori registrati. Se il codice di errore viene restituito utilizzando un parametro denominato, il nome del parametro dovrebbe (SHOULD) essere « error ».

Altri schemi capaci di essere utilizzati per l'autenticazione dei token OAuth, ma non progettati principalmente per tale scopo, possono (MAY) legare i loro valori di errore al registro nello stesso modo.

I nuovi schemi di autenticazione possono (MAY) anche scegliere di specificare l'uso dei parametri « error_description » e « error_uri » per restituire informazioni di errore in modo parallelo al loro utilizzo in questa specifica.

---