SAML2 vs. OAuth - ¿Cuáles son algunas relaciones razonables?

La única implementación de esta combinación que conozco es Salesforce. Lo que está buscando hacer es una configuración compleja: ambos protocolos no son simples y existen problemas en su interacción, como el que mencionó.

Eche un vistazo a este documento (cómo se ve la implementación de SF desde afuera) - enlace

y verifique este borrador (yo personalmente no lo había investigado, pero está abordando específicamente su caso enlace

Unir los marcos SAML y OAuth 2.0 es un problema bien entendido. La siguiente pila de especificaciones de IETF proporciona una solución estándar:

• Si observa la especificación OAuth 2.0 central (RFC 6749) y su token endpoint definition : este es básicamente un punto final del servidor OAuth que devuelve un token de acceso a cambio de un " grant ": un concepto abierto de algo que se considera apropiado para otorgar a la aplicación cliente el problema de un token de acceso . En el escenario típico de OAuth, este es un código de autorización que indica que el usuario ha sido autenticado y dado previamente su consentimiento. Pero la subvención también podría ser otra cosa.

• Hay una especificación adicional de IETF llamada draft-ietf-oauth-assertions-16 que se basa en el estándar RFC 6749 central que dice que la concesión también puede ser una afirmación (una prueba firmada de algo) y define los parámetros de solicitud de token necesarios para eso.

• Finalmente, hay draft-ietf-oauth-saml2-bearer- 20 , que especifica cómo esta aserción puede ser una aserción de portador SAML 2.0.

Este mecanismo estándar para convertir una aserción SAML en un token de acceso OAuth 2.0 es esencialmente todo lo que se necesita para unir los dos marcos.

Para garantizar que la eliminación de usuarios se refleje correctamente en los sistemas de autorización, existen dos enfoques que se pueden combinar:

• Haz que los tokens de acceso OAuth 2.0 sean de corta duración. Esto obligará al cliente a repetir el proceso de autorización cuando el token caduque, y si el usuario ya no existe, la autenticación fallará y no se emitirá ninguna concesión (aserción SAML).
• Proporcione una API para revocar tokens de acceso OAuth 2.0 emitidos, consulte RFC 7009 para obtener más detalles.

OAuth es un trabajo de marco autorización . desde RFC6749

  

El marco de autorización OAuth 2.0 permite a un tercero      Aplicación para obtener acceso limitado a un servicio HTTP

Y SAML es un marco de autenticación . Las aserciones de SAML contienen información de autenticación. Comúnmente, SAML se usa para SSO, pero el estándar SAML también contiene una %código%. Que se puede utilizar para llevar alguna información de autorización.

Puede obtener más información en la documentación de SAML aquí .

La pregunta no proporciona detalles sobre la implementación de su sistema, pero sugeriría usar las capacidades de autorización de SAML 2.0 en lugar de tratar de fusionar dos estándares completamente diferentes que sirven para diferentes propósitos