Actualizar tokens en OAuth2 con JWTs

3

Estoy intentando implementar el flujo de propietario de recursos OAuth2. Mi servidor de autorización genera correctamente tokens web JSON, por lo que mi siguiente paso es implementar tokens de actualización para mi aplicación web.

Todo lo que he leído explica que al solicitar un token de acceso desde su servidor de autorización, incluye la URL del servidor de recursos como client_id . Esto se pone luego en un reclamo de auditoría dentro de su JWT. ¿Esto es correcto?

Si es así, mi problema surge cuando intento implementar tokens de actualización. Los tokens de actualización se emiten por cliente, por lo que el campo client_id ahora necesita identificar al cliente, y no a la URL del servidor de recursos. Siendo este el caso, mi servidor de autorización ahora no sabe para quién emitir el token, por lo que no sabe qué agregar en la reclamación aud dentro del JWT.

Estoy buscando algunos consejos sobre el mejor enfoque para resolver este problema en relación con la especificación OAuth2, no parece haber una respuesta concreta para este problema al mezclar OAuth2 y JWT.

¿Alguien tiene alguna idea?

Mi flujo actual se ve así:

  1. El cliente envía la solicitud al servidor de autorización con el nombre de usuario en el campo username , la contraseña en el campo password y el servidor de recursos al que desea acceder en el campo client_id .

  2. El servidor de autorización valida el nombre de usuario y la contraseña, y comprueba si puede generar un JWT para el servidor de recursos solicitado.

  3. Devuelve un token si ambos cheques pasan, el token contiene una reclamación aud que coincide con el client_id que vino en la solicitud.

pregunta Developer 05.12.2015 - 13:20
fuente

1 respuesta

2
  

Todo lo que he leído explica que al solicitar un token de acceso desde su servidor de autorización, debe incluir la URL del servidor de recursos como ID de cliente. Esto se pone luego en un reclamo de auditoría dentro de su JWT. ¿Esto es correcto?

No, eso no es. El 'cliente' es una entidad que realiza la solicitud , y debe ser identificable y auditada independientemente del servidor de recursos (y puede haber varios clientes para el mismo recurso) .
Especificación de OAuth 2.0 proporciona la siguiente definición para client_id

  

una cadena única que representa la información de registro proporcionada por el cliente. El identificador de cliente es exclusivo del servidor de autorización.

Para flujo de propietario de recursos las credenciales del cliente solo se pueden omitir si el cliente no es confidencial ( enlace ), en otro caso, se preferiría la preinscripción (el cliente debe emitir un único client_id y un client_secret).

Por cierto, de acuerdo con la especificación usted no necesita cualquier credencial de cliente para actualizar el token de acceso . Los únicos parámetros necesarios son el tipo de concesión (se debe establecer en "refresh_token") y el token de actualización.

Con respecto al token JWT y la reclamación "aud"

  

La reclamación "aud" (audiencia) identifica a los destinatarios a los que está destinado el JWT. Cada principal destinado a procesar el JWT DEBE identificarse con un valor en el reclamo de audiencia.

En otras palabras, es un equivalente de JWT para client_id. Y las mismas reglas que para client_id son aplicables. Recomiendo ir a especificación de OpenID Connect que se construye sobre OAuth y tiene una gran cantidad de prescripciones sobre cómo trabajar con tokens JWT y el protocolo OAuth 2.0, así como una explicación detallada del uso de reclamos JWT.

Puedo sugerir las siguientes opciones para tu problema

  1. No use la declaración "aud" en el flujo del propietario del recurso, ya que es opcional para OAuth (pero se requiere para OpenID Connect)
  2. Emita un client_id real y complete "aud" con este valor (en realidad depende del tipo de cliente, es confidencial o no)
respondido por el Salamander 06.12.2015 - 21:54
fuente

Lea otras preguntas en las etiquetas