¿Cómo validar un token de acceso OAuth 2.0 para un servidor de recursos?

Cuando un cliente le pide a un servidor de recursos que obtenga un recurso protegido con un token de acceso OAuth 2.0, ¿cómo valida este servidor el token? ¿El protocolo de token de actualización OAuth 2.0?

Actualización de noviembre de 2015: según Hans Z. a continuación, esto ahora se define como parte de RFC 7662 .

Respuesta original: La especificación OAuth 2.0 ( RFC 6749 ) no define claramente la interacción entre un servidor de recursos (RS) y un servidor de autorización (AS) para la validación de token de acceso (AT). Realmente depende del formato / estrategia del token del AS: algunos tokens son autónomos (como JSON Web Tokens ), mientras que otros pueden ser similares a una cookie de sesión en el sentido de que solo hacen referencia a la información contenida en el servidor en el AS.

Se ha debatido en el Grupo de trabajo de OAuth sobre la creación de una forma estándar para que un RS se comunique con el AS para la validación de AT. Mi empresa (Ping Identity) ha ideado uno de estos enfoques para nuestro OAuth AS (PingFederate) comercial: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=lzn1564003025072.html#lzn1564003025072__section_N1057_N100_2572_N1_57.N1_25772_N1_1_57_100_2_257_N1_A_100_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_A_ " _ " ." Utiliza una interacción basada en REST para esto que es muy complementaria a OAuth 2.0.

Manera de Google

Validación de tokens de Google Oauth2

Solicitud:

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

Responder:

{
  "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
} 

Manera de Microsoft

Microsoft - Oauth2 verifica una autorización

Manera Github

Github - Oauth2 verifica una autorización

Solicitud:

GET /applications/:client_id/tokens/:access_token

Responder:

{
  "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"
  }
}

Manera amazónica

Iniciar sesión con Amazon - Guía para desarrolladores (diciembre de 2015, página 21)

Solicitud :

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

Respuesta:

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
}

Una actualización sobre la respuesta de @Scott T.: la interfaz entre el Servidor de recursos y el Servidor de autorización para la validación de tokens se estandarizó en IETF RFC 7662 en octubre de 2015, consulte: https://tools.ietf.org/html/rfc7662 . Una llamada de validación de muestra se vería así:

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

y una respuesta de muestra:

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"
}

Por supuesto, la adopción por parte de vendedores y productos tendrá que suceder con el tiempo.

La especificación OAuth 2.0 no define la parte. Pero podría haber un par de opciones:

1. Cuando el servidor de recursos obtiene el token en el encabezado Authz, llama a la API de validación / introspección en el servidor Authz para validar el token. Aquí el servidor Authz podría validarlo ya sea usando DB Store o verificando la firma y ciertos atributos. Como parte de la respuesta, decodifica el token y envía los datos reales del token junto con el tiempo de vencimiento restante.

2. Authz Server puede encriptar / firmar el token usando una clave privada y luego publickey / cert puede ser entregado a Resource Server. Cuando el servidor de recursos obtiene el token, descifra / verifica la firma para verificar el token. Saca el contenido y procesa el token. Luego puede proporcionar acceso o rechazar.

Las especificaciones de OAuth v2 indican:

Los atributos de token de acceso y los métodos utilizados para acceder a los recursos protegidos están más allá del alcance de esta especificación y están definidos por especificaciones complementarias.

Mi servidor de autorización tiene un punto final de servicio web (SOAP) que permite al servidor de recursos saber si access_token es válido.