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


147

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?


Se supone que el servidor puede validar el token que se ha emitido previamente ... Por lo general, se trata de una búsqueda en la base de datos o criptografía (tokens autofirmados).
Thilo

Veo. ¿Qué tal este caso, el propietario del recurso WS y el cliente WS están en dispositivos diferentes?
Ack

55
¿Te refieres al servicio de autenticación y al servicio de recursos? (el cliente / consumidor siempre estará en un dispositivo diferente y no puede validar los tokens él mismo). Si ese es el caso, puede usar tokens de actualización que son "caros" para verificar (solo el servidor de autenticación puede hacerlo) pero de larga duración y tokens de acceso que caducan con frecuencia y se pueden verificar sin conexión.
Thilo

Respuestas:


97

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.


Scott T, ¿Hay alguna forma de ver un ejemplo de código sobre cómo utilizar la función en Ping Federate?
JavaHead

2
@JavaHead hay más detalles de protocolo cubiertos en nuestro sitio web para desarrolladores aquí: developer.pingidentity.com/en/resources/… , PingFederate OAuth Playground se envía como un conjunto de JSP que puede ser referenciado como código fuente para validar tokens. Se puede descargar (y otras bibliotecas y ejemplos de código abierto) desde aquí: developer.pingidentity.com/en/code.html
Scott T.

Scott, estoy buscando una muestra que demuestre la concesión de credenciales de cliente con API de descanso protegida por un servidor de recursos local y PingFederate como el servidor de autenticación. El servidor de recursos local llamará al punto final de validación. ¿Te has encontrado con algo así?
JavaHead

@JavaHead nuevamente, eso es algo para lo que deberías poder hacer referencia en el PingFederate OAuth Playground. Demuestra el tipo de concesión de credenciales del cliente y la validación de un token de acceso por parte de un servidor de recursos.
Scott T.

En el caso de un token de acceso JWT, supongo que normalmente no querría alcanzar el punto final de introspección AS para cada solicitud entrante al RS. En cuyo caso, ¿es suficiente una verificación RS de la firma y el alcance del token? ¿O tal vez el RS podría almacenar en caché las respuestas de introspección del AS por un período de tiempo?
Gary

119

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
}

2
@gustavodiazjaimes No explica en absoluto cómo el lado del servidor reconoce la identificación de usuario asignada de un token.
user2284570

22
No entiendo todos los votos. Esto no parece responder la pregunta.
Duncan Jones

¿Alguien sabe si Azure Active Directory tiene un punto final similar para verificar si un token emitido es válido?
user180940

2
En otras palabras, rueda el tuyo.
AndroidDev

51

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.


Si usa OoenId Connect, ¿no deberíamos preferir la forma abierta de usar el token de identificación para validar el token de acceso: openid.net/specs/…?
Adnan Kamili

1
@Renan: para estar en línea con la forma en que se solicitan los ámbitos en una solicitud de autorización, que es con un scopeparámetro de consulta cuyo valor contiene una lista de ámbitos separados por espacios
Hans Z.

44
No utilice la palabra "estandarizado" cuando algo no haya sido oficialmente aceptado por un órgano rector. El IETF RFC 7662 a partir de febrero de 2018 indica claramente que es una "propuesta".
AndroidDev

1
@adnankamili No hay tal cosa como una "propuesta". Cuando un documento se convierte en un RFC, ya es un "estándar propuesto" que tiene un peso significativo detrás de él. OAuth 2.0 en sí mismo sigue siendo un "estándar propuesto", por lo que no estoy seguro de qué punto está tratando de hacer.
Pace

15

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.


8

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.