Come convalidare un token di accesso OAuth 2.0 per un server di risorse?

Quando un client chiede a un server risorse di ottenere una risorsa protetta con un token di accesso OAuth 2.0, in che modo questo server convalida il token? Il protocollo token di aggiornamento OAuth 2.0?

Aggiornamento novembre 2015: secondo Hans Z. di seguito - questo è ora definito come parte di RFC 7662 .

Risposta originale: le specifiche OAuth 2.0 ( RFC 6749 ) non definiscono chiaramente l'interazione tra un server risorse (RS) e un server di autorizzazione (AS) per la convalida del token di accesso (AT). Dipende molto dal formato / strategia del token dell'AS - alcuni token sono autonomi (come i token Web JSON ) mentre altri possono essere simili a un cookie di sessione in quanto fanno riferimento a informazioni conservate sul lato server nell'AS.

Nel gruppo di lavoro OAuth si è discusso della creazione di un modo standard per una RS di comunicare con l'AS per la convalida AT. La mia azienda (Ping Identity) ha messo a punto un approccio di questo tipo per il nostro commerciale OAuth AS (PingFederate): https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=lzn1564003025072.html#lzn1564003025072__section_N10578_N1002A_N10001 . Usa l'interazione basata su REST per questo che è molto complementare a OAuth 2.0.

Google way

Convalida token di Google Oauth2

Richiesta:

https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg

Rispondere:

{
  "audience":"8819981768.apps.googleusercontent.com",
  "user_id":"123456789",
  "scope":"https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "expires_in":436
} 

Microsoft Way

Microsoft - Oauth2 controlla un'autorizzazione

Modo di Github

Github - Oauth2 controlla un'autorizzazione

Richiesta:

GET /applications/:client_id/tokens/:access_token

Rispondere:

{
  "id": 1,
  "url": "https://api.github.com/authorizations/1",
  "scopes": [
    "public_repo"
  ],
  "token": "abc123",
  "app": {
    "url": "http://my-github-app.com",
    "name": "my github app",
    "client_id": "abcde12345fghij67890"
  },
  "note": "optional note",
  "note_url": "http://optional/note/url",
  "updated_at": "2011-09-06T20:39:23Z",
  "created_at": "2011-09-06T17:26:27Z",
  "user": {
    "login": "octocat",
    "id": 1,
    "avatar_url": "https://github.com/images/error/octocat_happy.gif",
    "gravatar_id": "somehexcode",
    "url": "https://api.github.com/users/octocat"
  }
}

Via dell'Amazzonia

Accedi con Amazon - Guida per gli sviluppatori (dicembre 2015, pagina 21)

Richiesta :

https://api.amazon.com/auth/O2/tokeninfo?access_token=Atza|IQEBLjAsAhRmHjNgHpi0U-Dme37rR6CuUpSR...

Risposta:

HTTP/l.l 200 OK
Date: Fri, 3l May 20l3 23:22:l0 GMT 
x-amzn-RequestId: eb5be423-ca48-lle2-84ad-5775f45l4b09 
Content-Type: application/json 
Content-Length: 247 

{ 
  "iss":"https://www.amazon.com", 
  "user_id": "amznl.account.K2LI23KL2LK2", 
  "aud": "amznl.oa2-client.ASFWDFBRN", 
  "app_id": "amznl.application.436457DFHDH", 
  "exp": 3597, 
  "iat": l3ll280970
}

Un aggiornamento sulla risposta di @Scott T.: l'interfaccia tra Resource Server e Authorization Server per la convalida dei token è stata standardizzata in IETF RFC 7662 nell'ottobre 2015, vedere: https://tools.ietf.org/html/rfc7662 . Una chiamata di convalida di esempio sarebbe simile a:

POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer 23410913-abewfq.123483

token=2YotnFZFEjr1zCsicMWpAA

e una risposta di esempio:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "active": true,
  "client_id": "l238j323ds-23ij4",
  "username": "jdoe",
  "scope": "read write dolphin",
  "sub": "Z5O3upPC88QrAjx00dis",
  "aud": "https://protected.example.net/resource",
  "iss": "https://server.example.com/",
  "exp": 1419356238,
  "iat": 1419350238,
  "extension_field": "twenty-seven"
}

Naturalmente l'adozione da parte di venditori e prodotti dovrà avvenire nel tempo.

Le specifiche OAuth 2.0 non definiscono la parte. Ma potrebbero esserci un paio di opzioni:

1. Quando il server delle risorse ottiene il token nell'intestazione Authz, chiama l'API validate / introspect sul server Authz per convalidare il token. Qui il server Authz potrebbe convalidarlo utilizzando DB Store o verificando la firma e alcuni attributi. Come parte della risposta, decodifica il token e invia i dati effettivi del token insieme al tempo di scadenza rimanente.

2. Authz Server può crittografare / firmare il token utilizzando la chiave privata e quindi publickey / cert può essere assegnato a Resource Server. Quando il server delle risorse ottiene il token, decodifica / verifica la firma per verificare il token. Elimina il contenuto ed elabora il token. Quindi può fornire accesso o rifiutare.

Le specifiche di OAuth v2 indicano:

Gli attributi del token di accesso e i metodi utilizzati per accedere alle risorse protette esulano dallo scopo di questa specifica e sono definiti dalle specifiche del compagno.

Il mio server di autorizzazione ha un endpoint del servizio Web (SOAP) che consente al server di risorse di sapere se access_token è valido.