Nuestros investigadores estrellas agotaron sus provisiones de café, investigando a tiempo completo por la respuesta, hasta que Samuel encontró el arreglo en GitHub por lo tanto en este momento la compartimos contigo.
Solución:
Resulta que mis sospechas eran correctas. La audiencia aud La reclamación en un JWT está destinada a hacer referencia a los servidores de recursos que deberían aceptar el token.
Como esta publicación simplemente lo pone:
La audiencia de un token es el destinatario previsto del token.
El valor de la audiencia es un string – normalmente, la dirección base del recurso al que se accede, como
https://contoso.com.
los client_id en OAuth se refiere a la aplicación cliente que solicitará recursos del servidor de recursos.
La aplicación Cliente (por ejemplo, su aplicación iOS) solicitará un JWT de su Servidor de autenticación. Al hacerlo, pasa su client_id y client_secret junto con las credenciales de usuario que puedan ser necesarias. El servidor de autorización valida al cliente mediante el client_id y client_secret y devuelve un JWT.
El JWT contendrá un aud afirmación que especifica para qué servidores de recursos es válido el JWT. Si el aud contiene www.myfunwebapp.com, pero la aplicación cliente intenta usar el JWT en www.supersecretwebapp.com, entonces se denegará el acceso porque ese servidor de recursos verá que el JWT no fue diseñado para él.
El JWT aud (Audiencia) Reclamo
Según RFC 7519:
La afirmación “aud” (audiencia) identifica a los destinatarios a los que está destinado el JWT. Cada director destinado a procesar el JWT DEBE identificarse con un valor en el reclamo de la audiencia. Si el principal que procesa el reclamo no se identifica con un valor en el reclamo “aud” cuando este reclamo está presente, entonces el JWT DEBE ser rechazado. En el caso general, el valor “aud” es un array de cadenas que distinguen entre mayúsculas y minúsculas, cada una de las cuales contiene un valor StringOrURI. En el caso especial en el que el JWT tiene una audiencia, el valor “aud” PUEDE ser un único que distingue entre mayúsculas y minúsculas string que contiene un valor StringOrURI. La interpretación de los valores de la audiencia generalmente es específica de la aplicación.
El uso de esta afirmación es OPCIONAL.
La audiencia (aud) La afirmación definida por la especificación es genérica y específica de la aplicación. El uso previsto es identificar los destinatarios previstos del token. Lo que significa un destinatario es específico de la aplicación. Un valor de audiencia es una lista de cadenas o puede ser una string si solo hay uno aud afirmar. El creador del token no hace cumplir ese aud se valida correctamente, el destinatario es responsable de determinar si se debe utilizar el token.
Cualquiera que sea el valor, cuando un destinatario está validando el JWT y desea validar que el token estaba destinado a ser utilizado para sus fines, DEBE determinar qué valor en aud se identifica a sí mismo, y el token solo debe validar si el ID declarado del destinatario está presente en el aud afirmar. No importa si se trata de una URL o de alguna otra aplicación específica string. Por ejemplo, si mi sistema decide identificarse en aud con el string: api3.app.com, entonces solo debe aceptar el JWT si el aud el reclamo contiene api3.app.com en su lista de valores de audiencia.
Por supuesto, los destinatarios pueden optar por ignorar aud, por lo que esto solo es útil si un destinatario desea una validación positiva de que el token se creó específicamente para él.
Mi interpretación basada en la especificación es que el aud La reclamación es útil para crear JWT especialmente diseñados que solo son válidos para ciertos propósitos. Para un sistema, esto puede significar que desea que un token sea válido para algunas funciones pero no para otras. Podrías emitir tokens que estén restringidos solo a una determinada “audiencia”, mientras sigues usando el mismo keys y algoritmo de validación.
Dado que en el caso típico, un JWT es generado por un servicio confiable y utilizado por otros sistemas confiables (sistemas que no quieren usar tokens inválidos), estos sistemas simplemente necesitan coordinar los valores que usarán.
Por supuesto, aud es completamente opcional y puede ignorarse si su caso de uso no lo justifica. Si no desea restringir los tokens para que sean utilizados por audiencias específicas, o ninguno de sus sistemas validará la aud token, entonces es inútil.
Ejemplo: tokens de acceso y actualización
Un ejemplo artificial (aunque simple) en el que puedo pensar es que quizás queremos usar JWT para acceder y actualizar tokens sin tener que implementar un cifrado por separado. keys y algoritmos, pero simplemente desea asegurarse de que los tokens de acceso no se validen como tokens de actualización, o viceversa.
Mediante el uso aud, podemos especificar un reclamo de refresh para actualizar tokens y un reclamo de access para tokens de acceso al crear estos tokens. Cuando se realiza una solicitud para obtener un nuevo token de acceso de un token de actualización, debemos validar que el token de actualización era un token de actualización genuino. los aud La validación como se describe anteriormente nos dirá si el token era en realidad un token de actualización válido al buscar específicamente un reclamo de refresh en aud.
ID de cliente de OAuth frente a JWT aud Afirmar
El ID de cliente de OAuth no está relacionado en absoluto y no tiene una correlación directa con JWT aud reclamación (es. Desde la perspectiva de OAuth, los tokens son objetos opacos.
La aplicación que acepta estos tokens es responsable de analizar y validar el significado de estos tokens. No veo mucho valor en especificar el ID de cliente OAuth dentro de un JWT aud afirmar.
Si vino aquí buscando OpenID Connect (OIDC): OAuth 2.0! = OIDC
Reconozco que esto está etiquetado para oauth 2.0 y NO OIDC, sin embargo, con frecuencia existe una combinación entre los 2 estándares, ya que ambos estándares pueden utilizar JWT y el aud afirmar. Y uno (OIDC) es básicamente una extensión del otro (OAUTH 2.0). (Me encontré con esta pregunta buscando OIDC yo mismo).
Tokens de acceso de OAuth 2.0 ##
Para OAuth 2.0 Tokens de acceso, las respuestas existentes lo cubren bastante bien. Además, aquí hay una sección relevante de OAuth 2.0 Framework (RFC 6749)
Para los clientes públicos que utilizan flujos implícitos, esta especificación no proporciona ningún método para que el cliente determine a qué cliente se emitió un token de acceso.
…
La autenticación de los propietarios de recursos ante los clientes está fuera del alcance de esta especificación. Cualquier especificación que utilice el proceso de autorización como una forma de autenticación delegada del usuario final al cliente (por ejemplo, servicio de inicio de sesión de terceros) NO DEBE usar el flujo implícito sin mecanismos de seguridad adicionales que permitan al cliente determinar si el acceso token fue emitido para su uso (por ejemplo, audiencia – restringiendo el token de acceso).
Tokens de ID de OIDC ##
OIDC tiene Tokens de identificación además de los tokens de acceso. La especificación OIDC es explícita sobre el uso de la aud reclamo en tokens de identificación. (openid-connect-core-1.0)
aud
REQUERIDO. Público (s) a los que está destinado este token de identificación. DEBE contener el client_id de OAuth 2.0 de la parte de confianza como valor de audiencia. PUEDE también contener identificadores para otras audiencias. En el caso general, el valor aud es un array de cadenas sensibles a mayúsculas y minúsculas. En el caso especial común cuando hay una audiencia, el valor de aud PUEDE ser una única sensible a mayúsculas y minúsculas string.
además OIDC especifica el azp afirmación que se utiliza junto con aud cuando aud tiene más de un valor.
azp
OPCIONAL. Parte autorizada: la parte a la que se emitió el token de identificación. Si está presente, DEBE contener el ID de cliente OAuth 2.0 de esta parte. Este reclamo solo es necesario cuando el token de identificación tiene un valor de audiencia único y esa audiencia es diferente a la parte autorizada. PUEDE incluirse incluso cuando la parte autorizada sea la misma que la única audiencia. El valor azp distingue entre mayúsculas y minúsculas string que contiene un valor StringOrURI.
Calificaciones y reseñas
Al final de todo puedes encontrar los comentarios de otros creadores, tú igualmente tienes la opción de insertar el tuyo si lo crees conveniente.