Estoy trabajando en la implementación de OAuth 2.0 JWT access_token en mi servidor de autenticación. Pero no tengo claro cuáles son las diferencias entre el audreclamo de JWT y el client_idvalor del encabezado HTTP. ¿Son lo mismo? Si no es así, ¿puede explicar la diferencia entre los dos?

Mi sospecha es que auddebería hacer referencia a los servidores de recursos, y client_iddebería hacer referencia a una de las aplicaciones cliente reconocidas por el servidor de autenticación (es decir, aplicación web o aplicación iOS).

En mi caso actual, mi servidor de recursos también es mi cliente de aplicación web.

Resulta que mis sospechas eran correctas. El audreclamo de audiencia en un JWT está destinado 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 una cadena; por lo general, la dirección base del recurso al que se accede, como https://contoso.com.

En client_idOAuth 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 que es client_idy client_secretjunto con las credenciales de usuario que pueden ser necesarios. El servidor de autorización valida al cliente mediante client_idy client_secrety devuelve un JWT.

El JWT contendrá un audreclamo que especifica para qué servidores de recursos es válido el JWT. Si audcontiene www.myfunwebapp.com, pero la aplicación cliente intenta usar el JWT activado www.supersecretwebapp.com, se denegará el acceso porque el servidor de recursos verá que el JWT no fue diseñado para ello.

El audreclamo de JWT (audiencia)

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 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 una matriz de cadenas que distinguen entre mayúsculas y minúsculas, cada una de las cuales contiene un valor StringOrURI. En el caso especial cuando el JWT tiene una audiencia, el valor "aud" PUEDE ser una única cadena sensible a mayúsculas y minúsculas 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 audafirmación Audience ( ) tal como se define en 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 sola cadena si solo hay un audreclamo. El creador del token no hace cumplir que audesté validado correctamente, la responsabilidad es del destinatario 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 se audidentifica a sí mismo, y el token solo debe validar si la identificación declarada del destinatario es presente en la audreclamación. No importa si se trata de una URL o de alguna otra cadena específica de la aplicación. Por ejemplo, si mi sistema decide identificarse audcon la cadena: api3.app.comentonces solo debería aceptar el JWT si el audreclamo contiene api3.app.comen 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 la audafirmació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 válido para otras. Podrías emitir tokens que estén restringidos solo a una determinada "audiencia", mientras sigues usando las mismas claves 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, audes 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 realmente validará el audtoken, entonces es inútil.

Ejemplo: tokens de acceso y actualización

Un ejemplo artificial (aunque simple) en el que puedo pensar es que tal vez queremos usar JWT para acceder y actualizar tokens sin tener que implementar claves de cifrado y algoritmos separados, pero simplemente queremos asegurarnos de que los tokens de acceso no se validen como tokens de actualización, o viceversa. -versa.

Al usar aud, podemos especificar un reclamo de refreshtokens de actualización y un reclamo de accesstokens 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. La audvalidación descrita anteriormente nos dirá si el token era en realidad un token de actualización válido al buscar específicamente un reclamo de refreshin aud.

ID de cliente de OAuth frente a audreclamación de JWT

El ID de cliente de OAuth no está relacionado en absoluto y no tiene una correlación directa con los audreclamos de JWT . 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 de OAuth dentro de un audreclamo de JWT .

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 hay una combinación entre los 2 estándares, ya que ambos estándares pueden usar JWT y el audreclamo. 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 los tokens de acceso de OAuth 2.0 , 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, un 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 El token se emitió 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 tokens de acceso. La especificación OIDC es explícita sobre el uso del audreclamo en los 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. También PUEDE contener identificadores para otras audiencias. En el caso general, el valor aud es una matriz de cadenas que distinguen entre mayúsculas y minúsculas. En el caso especial común cuando hay una audiencia, el valor aud PUEDE ser una única cadena sensible a mayúsculas y minúsculas.

además, OIDC especifica la azpafirmación que se utiliza junto con audwhen audtiene 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 es una cadena sensible a mayúsculas y minúsculas que contiene un valor StringOrURI.

Aunque esto es antiguo, creo que la pregunta es válida incluso hoy

Mi sospecha es que aud debería referirse a los servidores de recursos, y el client_id debería referirse a una de las aplicaciones cliente reconocidas por el servidor de autenticación.

Sí, aud debe referirse a la parte consumidora de tokens. Y client_id se refiere a la fiesta de obtención de tokens.

En mi caso actual, mi servidor de recursos también es mi cliente de aplicación web.

En el escenario del OP, la aplicación web y el servidor de recursos pertenecen a la misma parte. Entonces esto significa que el cliente y la audiencia deben ser iguales. Pero puede haber situaciones en las que este no sea el caso.

Piense en un SPA que consume un recurso protegido por OAuth. En este escenario, SPA es el cliente. El recurso protegido es la audiencia del token de acceso.

Este segundo escenario es interesante. Existe un borrador de trabajo llamado " Indicadores de recursos para OAuth 2.0 " que explica dónde puede definir la audiencia prevista en su solicitud de autorización. Entonces, el token resultante se restringirá a la audiencia especificada. Además, Azure OIDC usa un enfoque similar en el que permite el registro de recursos y permite que la solicitud de autenticación contenga un parámetro de recurso para definir la audiencia prevista del token de acceso. Dichos mecanismos permiten que las asignaciones de OAuth tengan una separación entre el cliente y la parte consumidora de tokens (audiencia).