ADFS 2012 R2 (3.0) Validación del token web JSON

Si entiendo su pregunta correctamente, la firma es un RSASSA que utiliza el hash SHA-256 según el configurado Certificado de firma de token .

Tengo un ejemplo de validación de Node.js en GitHub y aquí hay un publicación de blog con algunos detalles más.

He estado tratando de responder esta misma pregunta durante los últimos días. Parece que la implementación de Windows Server 2012 R2 ADFS 3.0 de OAUTH2 requiere el uso de certificados en lugar de un secreto compartido si desea cifrar / firmar la respuesta JWT. Habiendo usado OAUTH2 con múltiples aplicaciones web que no son de Microsoft, siempre he visto secretos compartidos y no certificados. Apostaría a que el estándar OAUTH2 permite cualquiera de los dos, pero Microsoft optó por lo que saben en su primera implementación del estándar.

Hasta ahora, he visto una cita de un blog de empleados de Microsoft que me hace pensar que lo que vemos como "estándar" OAUTH2 no es compatible con ADFS 3.0:

De enlace

  

Los JWT emitidos por ADFS en Windows Server 2012 R2 se firman utilizando el certificado de emisión de ADFS. ADFS no admite el cifrado JWT.

Además, Lo nuevo en ADFS para Windows Server 2016 señala que los secretos compartidos serán una nueva característica:

(Lo siento por los enlaces que no pertenecen a los enlaces. Como no tengo reputación aquí, solo puedo incluir un enlace en esta publicación). De technet.microsoft.com/en-us/library/mt617220.aspx (énfasis mío)

  

AD FS para Windows Server 2016 se basa en el soporte del protocolo Oauth que se introdujo en Windows Server 2012 R2, para permitir los flujos de autenticación más actuales y basados en los estándares de la industria entre las aplicaciones web, las API web, el navegador y aplicaciones nativas basadas en clientes.   Windows Server 2012 R2 ofreció soporte para el flujo de concesión de autorización de Oauth y el tipo de concesión de código de autorización, solo para clientes públicos.   En Windows Server 2016, se admiten los siguientes protocolos y características adicionales:

     

• compatibilidad con OpenId Connect
  
• Tipos de concesión de código de autorización de Oauth adicionales      
  • Flujo implícito (para aplicaciones de una sola página)
    
  • Contraseña del propietario del recurso (para aplicaciones de scripting)
    
  
• Clientes confidenciales de Oauth (clientes capaces de mantener su propio secreto, como la aplicación o el servicio que se ejecuta en el servidor web)
  
• métodos de autenticación de clientes confidenciales de Oauth      
  • Simétrico (secreto compartido / contraseña)
    
  • Claves asimétricas
    
  • Autenticación integrada de Windows (WIA)
    
  
• El soporte para "en nombre de" fluye como una extensión del soporte básico de Oauth.
  

Para más información, consulte Habilitación de clientes confidenciales de Oauth con AD FS 2016 y Habilitación de OpenId Connect con AD FS 2016

Como desarrollador, configurar un cuadro de IIS en el dominio con una página de controlador (ASHX) que verifica al usuario del dominio y redirige al usuario a la aplicación web con un JWT cifrado mediante la clave compartida es una solución simple hasta que Windows Server 2016 esté disponible. Tenemos un código de ejemplo sobre cómo hacer esto en el foro de nuestra aplicación: connectionsonline.zendesk.com/entries/82271995-Single-Sign-on-Authentication-SSO-with-OAuth-2-0

Si puede obtener el token JWT, entonces la vida se vuelve más fácil con WebAPI, para la aplicación C # que puede usar el siguiente código (paquete de nuget Owin)

app.UseActiveDirectoryFederationServicesBearerAuthentication(
new ActiveDirectoryFederationServicesBearerAuthenticationOptions
{
    Audience = "The AppId Registered In ADFS",
    MetadataEndpoint = "https://fs.domain.com/federationmetadata/2007-06/federationmetadata.xml"
});

vea el blog secure-a-web-api-with-adfs en el servidor de Windows 2012-r2 here