OAuth2 JWT Firmando con la clave secreta de la aplicación OAuth2

4

Resumen (lo siento, esto es un bocado):

Me gustaría facilitar la Autorización back-end de sistema a sistema a través de OAuth2 y JWT haciendo uso del parámetro 'aud' de JWT para especificar un recurso específico para una aplicación (a través de una solicitud de concesión de Autorización de JWT al Servidor de Autorizaciones) y, a continuación, haga que el Servidor de autorización firme (o cifre) el JWT con la clave secreta OAuth2 de la aplicación OAuth2 registrada que contiene el recurso especificado por el parámetro 'aud' para que el Servidor de recursos para el que se solicitó un token pueda validar el token con su clave secreta de aplicación OAuth2.

Summary:

Tengo una pregunta relacionada con la Autorización back-end de sistema a sistema con OAuth2 y JWT.

  • Dado un RA de servidor de recursos
  • Y un servidor de recursos RB
  • Y un servidor de autorización AS
  • Y RA y RB son aplicaciones OAuth2 registradas con AS

Nos gustaría hacer uso de la especificación OAuth2 con JWT para lograr lo siguiente:

  1. RA solicita un JWT de AS
  2. AS responde a RA con un JWT
  3. RA solicita un recurso de RB utilizando JWT
  4. RB responde a RA con los datos de recursos (sin tener que llamar a AS)

El problema:

El objetivo es que RB tenga la capacidad de validar el JWT independientemente de AS. Dicho esto, RB debe tener una forma de validar el JWT que RA envió la solicitud. Desde que AS emitió el JWT enviado por RA, entonces AS y RB DEBEN tener un secreto compartido.

Sería una mala práctica de seguridad tener un secreto compartido entre todos los servidores de recursos y el servidor de autorización con el propósito expreso de usarlo para la firma y / o encriptación JWT. Esta solución haría a un lado la especificación OAuth2 (Delegación de Autorización) que ha intentado minuciosamente mitigar los problemas de seguridad que surgen de las claves simétricas distribuidas en gran medida, etc.

Propuesta:

Mi propuesta aproximada es resolver este problema es el siguiente:

  1. RA solicita un JWT de AS mediante la concesión de Autorización JWT y especifica un recurso en la API de RB en el parámetro 'aud' ( enlace ver número '3' '
  2. AS responde con un JWT firmado / encriptado con la clave secreta de la aplicación RB (AS puede identificar qué aplicación secreta se debe usar según el URI del parámetro 'aud')
  3. RA solicita un recurso en RB usando JWT
  4. RB valida el JWT firmado / cifrado usando la clave secreta OAuth2

Mi pregunta:

¿Tiene sentido la propuesta aquí? ¿Existe una implementación mucho más sencilla que aún cumpla con mi objetivo y permanezca dentro de la especificación OAuth2? ¿Es este un mal uso del parámetro 'aud' JWT?

Muchas gracias por leer esto y por tu ayuda.

    
pregunta Will Sulzer 05.01.2016 - 21:00
fuente

1 respuesta

1

Esto parece un caso en el que el nuevo servicio de introspección agregado a OAuth2 ( enlace ) podría ser útil. Le permite a su RB validar el token de acceso (JWT) reenviado por RA contra el AS.

Esto interrumpe su solicitud de que no hay comunicación entre RB y el AS. Pero eso no debería ser un problema, ya que estos servicios ya se confían entre sí. No hay claves simétricas conocidas globalmente ni confianzas implícitas entre RA y RB involucrados.

Interpolando en tu flujo:

  1. RA solicita un JWT de AS
  2. AS responde a RA con un JWT
  3. RA solicita un recurso de RB utilizando JWT
  4. RB valida el JWT contra el servicio AS / introspection
  5. RB responde a RA con los datos de recursos
respondido por el Geir Emblemsvag 06.01.2016 - 06:46
fuente

Lea otras preguntas en las etiquetas