Passa al contenuto principale

2.2. Access Token Request (Richiesta di access token)

2.2. Access Token Request (Richiesta di access token)​

Quando il parametro resource è usato in una richiesta di access token al token endpoint, per tutti i grant type, indica il servizio di destinazione o la risorsa protetta dove il client intende usare l'access token richiesto.

Il o i valori di risorsa accettabili per un server di autorizzazione nell'adempiere una richiesta di access token sono a sua esclusiva discrezione in base a policy o configurazione locale. Nel caso di una richiesta di grant type refresh_token o authorization_code, tale policy può limitare le risorse accettabili a quelle originariamente concesse dal resource owner o a un sottoinsieme di esse. Nel caso authorization_code in cui le risorse richieste sono un sottoinsieme dell'insieme di risorse originariamente concesse, il server di autorizzazione emetterà un access token basato su quel sottoinsieme di risorse richieste, mentre qualsiasi refresh token restituito è vincolato all'intera concessione originale.

Quando si richiede un token, il client può indicare il o i servizi di destinazione desiderati dove intende usare quel token tramite il parametro resource e può indicare lo scope desiderato del token richiesto usando il parametro scope. La semantica di tale richiesta è che il client chiede un token con lo scope richiesto utilizzabile su tutti i servizi di destinazione richiesti. In effetti, i diritti di accesso richiesti del token sono il prodotto cartesiano di tutti gli scope su tutti i servizi di destinazione. Per quanto possibile, quando emette access token, il server di autorizzazione dovrebbe ridurre (downscope) il valore di scope associato a un access token al valore che la rispettiva risorsa è in grado di elaborare e deve conoscere. (Qui "downscope" significa concedere meno permessi di quanti originariamente autorizzati dal resource owner.) Ciò migliora ulteriormente la privacy poiché un elenco di valori di scope è un'indicazione che il resource owner usa i vari servizi elencati; ridurre un token solo a ciò che serve per un particolare servizio può limitare la misura in cui tali informazioni sono rivelate tra servizi diversi. Come specificato nella sezione 5.1 di [RFC6749], il server di autorizzazione deve indicare lo scope effettivo dell'access token al client nel valore del parametro di risposta scope quando differisce dallo scope richiesto dal client.

Seguendo la richiesta di autorizzazione in flusso con codice mostrata nella Figura 2, gli esempi sotto mostrano una richiesta di access token di grant type authorization_code (Figura 3) e la risposta (Figura 4) in cui il client comunica al server di autorizzazione che desidera l'access token per l'uso presso https://cal.example.com/ (interruzioni di riga e indentazione extra solo a scopo di visualizzazione).

POST /as/token.oauth2 HTTP/1.1
Host: authorization-server.example.com
Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ
&resource=https%3A%2F%2Fcal.example.com%2F

Figura 3: Richiesta di access token

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
   "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
    JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
    iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgwMCwic2NvcGUiOiJjYWxlbmRhciIs
    ImF1ZCI6Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyJ9.nNWJ2dXSxaDRdMUK
    lzs-cYIj8MDoM6Gy7pf_sKrLGsAFf1C2bDhB60DQfW1DZL5npdko1_Mmk5sUf
    zkiQNVpYw",
   "token_type":"Bearer",
   "expires_in":3600,
   "refresh_token":"4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2",
   "scope":"calendar"
}

Figura 4: Risposta access token

Una successiva richiesta di access token, usando il refresh token, in cui il client comunica al server di autorizzazione che desidera un access token per l'uso presso https://contacts.example.com/ è mostrata nella Figura 5 sotto con la risposta nella Figura 6 (interruzioni di riga e indentazione extra solo a scopo di visualizzazione).

POST /as/token.oauth2 HTTP/1.1
Host: authorization-server.example.com
Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2
&resource=https%3A%2F%2Fcontacts.example.com%2F

Figura 5: Richiesta di access token

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
   "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
    JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
    iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs
    ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc
    OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH
    UowfmtNaA5EikYAw",
   "token_type":"Bearer",
   "expires_in":3600,
   "scope":"contacts"
}

Figura 6: Risposta access token

Ultimo aggiornamento il